•  * 


AD-A274  691 

iiiiiiini 


DTfC 

JAN14F^'' 


CONSORTIUM  REQUIREMENTS 
ENGINEERING  GUIDEBOOK 

SPC-92060-CMC 


VERSION  01.00.09 
DECEMBER  1993 


94-01392 


9^  1 


11  180 


DUG  QTJALITY  INSPECTED  Q 


CONSORTIUM  REQUIREMENTS 
ENGINEERING  GUIDEBOOK 


SPC-92060-CMC 

VERSION  01.00.09 
DECEMBER  1993 


Accesion  For 

/ 

NTIS 

CRA&I 

one 

tab 

a 

Undenounced 

□ 

By 

Diutribution  1 

Aviiilability  Codes 

Avail  • 

ind/or  1 

Oisi 

Special 

Fktxluced  the 

SOFTWARE  PRODUCITVITY  CONSOKIIUM  SERVICES  CORPORAnON 

under  contract  to  the 

VmOINIA  CENTER  OF  EXCELLENCE 
FOR  SOFTWARE  REUSE  AND  TECHNOLOGY  TRANSFER 

SPC  Building 
2214  Rode  HDl  Road 
Herndon,  Virginia  22070 

Cofyright  ®  1992, 1993,  Software  Roduedvity  Ccosoitium  Services  Corporatioo,  Herndon,  Vir^nia.  Permisaon  to  use,  copy, 
nxx^,  and  dstiibute  this  material  for  ai^  purpose  and  without  fee  is  ber^  granted  conristent  with  48  CFR  227  and  252,  and 
provided  drat  the  above  oopyri^  notice  appears  in  an  001^  and  that  both  tte  copyri^t  notice  and  this  pennissioa  notice  appear 
insqipcrtingdocumentation.'nusmaterial  is  based  in  part  iqronwoikqpoiisofedbythe  AdvarxsedReseardilYcgects  Agency  under 
Grant  #MDA972-92J4018.  The  content  does  not  necessa^  rdlect  the  position  or  the  policy  of  the  U.  S.  Government,  and  no 
officuJ  endorsement  rixxild  be  infened.  The  name  Software  Roductivify  Consortium  shall  not  be  used  in  advertising  or  puNicity 
pertah^  to  this  material  or  otherwise  without  the  prior  written  permisrionc^SoftwarelVoductivity  Consortium,  Inc.  SOFTWARE 
PRODUenvnY  consortium,  INC  AND  SOFTWARE  PRODUCTTVTTY  CONSOKITUM  SERVICES 
CORPORAHON  MAKE  NO  REPRESENIAIIONS  OR  WARRANTEES  ABOUT  THE  SUTTABEUrTY  OF  THIS 
MAIERIAL  FOR  ANY  PURPOSE  OR  ABOUT  ANY  OTHER  MATTER,  AND  THIS  MATERIAL  IS  PROVIDED 
WITHOUT  EXPRESS  OR  IMPLIED  WARRANTY  OF  ANY  KIND. 


CONTENTS 


ACKNOWLEDGMENTS .  xvll 

1.  INTRODUCTION .  1-1 

1.1  Purpose  of  Hiis  Guidebook .  1-2 

1.2  Intended  Audience .  1-2 

13  Scope  of  the  Method  and  Guidebook  .  1-3 

1.4  Organization  of  the  Guidebook  .  1-3 

13  Using  This  Guidebook .  1-4 

1.6  '^pographic  Conventions  .  14 

2.  THE  Core  MODELS  .  2-1 

2.1  Core  Process  Overview .  2-2 

2.2  Purpose  of  the  CoRE  Models .  2-2 

2.2.1  Rationale  for  the  CoRE  Approach .  2-3 

2.2.2  Purpose  of  the  Behavioral  and  Class  Models  .  2-3 

23  The  Core  Behavioral  Model .  2-5 

23.1  Environmental  Variables .  2-5 

2.3.2  The  CoRE  Relations  .  2-5 

2.3.3  Relations  NAT  and  REQ  .  2-8 

23.3.1  Relation  NAT .  2-8 

2.33.2  Relation  REQ .  2-9 

23.4  Relations  IN  and  OUT .  2-9 

2.4  The  CoRE  Qass  Model .  2-11 

2.4.1  Objects  and  Classes  .  2-11 


Conieios 


2.4.2  Packaging  Relationships  Among  Classes .  2-12 

2.4.2. 1  Encapsulates  .  2-12 

2.4.2.2  Depends-on . 2-13 

2.4.2.3  Generalization/Specialization  .  2-14 

2.4.3  Allocating  the  Behavioral  Model  to  Classes .  2-lS 

3.  AN  EXAMPLE:  THE  FUEL  LEVEL  MONITORING  SYSTEM .  3-1 

4.  REPRESENTING  THE  CoRE  BEHAVIORAL  MODEL .  4-1 

4.1  Representing  the  Functional  View .  4-3 

4.1.1  Monitored  and  Controlled  Variables .  4-3 

4.1.2  Conditions .  4-3 

4.1.3  Events  and  Event  Expressions .  4-4 

4.1J.1  Definitions .  4-4 

4.1.3.2  Implementation  Considerations  .  4-5 

4.1.4  Tferms . ’. .  4-5 

4.1.5  Capturing  State  History .  4-6 

4.1.5.1  Modes  and  Mode  Machines .  4-6 

4.1.5.2  Mode  Transition  Diagram  .  4-7 

4.1.5.3  Mode  Transition  Thbles  .  4-7 

4.15  A  Properties  of  Mode  Machines .  4-9 

4.1.6  Tkbular  Representation  of  Functions .  4-9 

4.1.6.1  Condition  Tkble .  4-10 

4.1.6.2  Event  Thble  .  4-10 

4.1.6.3  Selector  Thble  .  4-12 

4.2  Representing  the  Dynamic  \Tew  .  4-12 

4.2.1  Periodic  Sdieduling  .  4-13 

4.2.2  Demand  Scheduling .  4-14 

4.3  Specifying  REQ,  NAT,  and  Undesired  Events  .  4-15 


43.1  Specifying  Controlled  Variable  Behavior .  4-15 

433  Specifying  NAT  Relations  .  4-16 

4.3.3  Specifying  Required  Responses  to  Undesired  Events  .  4-17 

5.  REPRESENTING  THE  CoRE  CLASS  MODEL .  5-1 

5.1  Information  Model .  5-1 

5.1.1  Generalizaticm/SpecializationRelationship .  5-3 

5.13  Aggregation .  5-3 

5.13  Apfdication-Spedfic  Relationship .  5-4 

53  Qass  Definitions  .  5-4 

5.3  Diagraming  Conventions .  5-6 

5.3.1  Context  Diagram .  5-6 

5.3.2  Dependency  Graph .  5-7 

533  Leveling .  5-8 

5.4  Qass  Spedfication .  5-9 

5.4.1  Class  Interface .  5-9 

5.4.2  Qass  Encapsulated  Information .  5-10 

5.43  Objects .  5-10 

5.4.4  Inheritance .  5-12 

53  Class  Model  Notation  Summary .  5-14 

6.  Core  PROCESS  OVERVIEW  .  6-1 

6.1  The  Idealized  Core  Process  .  6-1 

i 

6.1.1  Identify  Environmental  Variables .  6-3 

6.13  Preliminary  Behavior  Specification  .  6-4 

6.13  Qass  Structuring .  6-4 

6.1.4  Detailed  Behavior  Spedfication .  6-5 

6.13  Define  Hardware  Interface .  6-6 


6.2  CoRE  in  Practice 


6-7 


Cqbimiii 

62.1  Spedfying  Required  Behavior .  6-7 

6.2.2  Iteration  Among  Core  Activities  .  6-11 

6.23  Managing  Requirements  Development .  6-12 

7.  mENTIFYENVmONMENTAL  VARIABLES .  7-1 

7.1  Goals . 7-1 

12  Entrance  Criteria .  7-2 

73  Activities  .  7-2 

73.1  Identify  and  Define  Attributes  .  7-3 

733  Identify  Entities  .  7-5 

733  Identify  Generalization/Specialization  Relation .  1-5 

73.4  Identify  Aggregation  Relation .  7-6 

733  Identify  .^>plication-Specific  Relation .  7-6 

73.6  Identify  Likely  Requirements  Changes  and  Associated  ^^ables .  7-9 

7.4  Evaluation  Criteria .  7-10 

73  Exit  Criteria  .  7-10 

8.  PRELIMINARY  BEHAVIOR  SPECIFICATION  .  8-1 

8.1  Goals  .  8-1 

83  Entrance  Criteria .  8-2 

83  Activities .  8-2 

83.1  Identify  and  Define  Monitored  and  Controlled  Variables .  8-2 

8.3.1. 1  Identify  Controlled  Variables .  8-2 

83.1.2  Identify  Monitored  Variables .  8-3 

8.3.13  Define  Monitored  and  Controlled  Variables .  8-5 

83.1.4  Create  the  System  Context  Diagram .  8-7 

8.33  Establish  Controlled  Variable  Function  Domains .  8-7 

8.3.2.1  Identify  Monitored  Variables .  8-8 

8.3.2.2  Identify  Modes .  8-9 


8.3^  Identify  Scheduling  Requirements  .  8>9 

8.3.3  Define  Mode  Machines .  8-10 

8.3.3.1  Identify  Mode  Machines  .  8-10 

8.33.2  Identify  Modes  and  Hansitions .  8-11 

8.4  Evaluation  Criteria .  8-12 

83  Edt  Criteria  .  8-13 

9.  CLASS  STRUCTURING .  9-1 

9.1  Goals .  9-1 

9.2  Entrance  Criteria .  9-2 

9.3  Class  Structuring  Activities .  9-2 

9.3.1  Create  Boundary  Gasses .  9-3 

9.3.1.1  Allocate  Monitored  and  Controlled  Variables .  9-3 

9.3.13  Define  the  Boundary  Class  Interface .  9-4 

9.3.2  Create  Mode  Classes .  9-7 

9.3.3  Create  Iferm  Gasses .  9-7 

9.3.4  Define  the  Encapsulation  Structure .  9-8 

9.3.5  Define  the  Generalization/Spedaiization  Structure .  9-9 

9.3.6  Establish  Dependendes .  9-10 

9.4  Evaluation  Criteria .  9-12 

9.4.1  Evaluating  Gasses  .  9-12 

9.4.2  Evaluating  Gass  Dependendes  .  9-14 

9.5  Ejdt  Criteria  .  9-14 

10.  DETAILED  BEHAVIOR  SPEanCATION  .  10-1 

10.1  Goals .  10-1 

10.2  Entrance  Criteria .  10-1 

103  Activities .  10-2 


10.4  Define  Controlled  Variable  Behavior 


10-2 


CoBtemi _ 

10.4.1  Specify  Initial  ^^ue .  10-3 

10.4.2  Define  Sustaining  Conditions .  10-3 

10.43  Spedfy  Demand  Behavior .  10-4 

10.43.1  Specify  Demand  Functions .  10-4 

10.4.33  Demand  Sdteduling  and  Timing  Constraints .  10-S 

10.4.4  Specifying  Periodic  Behavior .  10-6 

10.4.4.1  Specify  Periodic  Rinctions .  10-6 

10.4.43  Specify  Periodic  Scheduling  and  Timing .  10-8 

10.43  Spedfy  Tblerance  Constraints .  10-9 

103  Refine  Mode  Gasses .  10-9 

10.6  Refine  Remaining  Gasses .  10-10 

10.7  Revisit  Class  Structuring .  10-10 

10.8  Evaluation  Criteria .  10-11 

10.8.1  Completeness  .  10-11 

10.8.2  Consistent^ .  10-12 

10.9  Eadt  Criteria  .  10-12 

11.  DEFINE  HARDWARE  INTERFACE .  11-1 

11.1  Goals .  11-1 

113  Entrance  Criteria .  11-2 

113  Activities .  11-2 

11.3.1  Assign  Input  and  Output  Variables  to  Boundary  Gasses .  11-2 

113.2  Define  Input  and  Output  \hriables  .  11-2 

t 

1133  Define  IN  and  OUT  Relations  .  11-3 

1133.1  Define  IN  for  a  Monitored  Variable .  11-4 

1133.2  Define  OUT  for  a  Controlled  Variable  .  11-5 

11.4  Evaluation  Criteria .  11-6 


113  Exit  Criteria 


11-7 


12.  ANALYZING  A  CoRE  SPECIFICATION  .  12-1 

12.1  Monitored  and  Controlled  Enables .  12-1 

V 

12.2  Controlled  \^riable  Fbncdons  .  12-1 

123  Ibrms  and  Modes .  12-2 

12.4  IN  and  OUT  Relations  .  12-3 

123  CHobal  Checks .  12-3 

APPENDIX  A.  SOFTWARE  REQUIREMENTS  FOR  THE  FUEL 

LEVEL  MONITORING  SYSTEM .  A-1 

A.1  Introduction .  A-1 

A. 2  Requirements  for  the  Fuel  Level  Monitoring  System .  A-1 

APPENDIX  B.  Core  SPECIFICATION  OF  THE  SOFTWARE 

REQUIREMENTS  FOR  THE  FUEL  LEVEL  MONITORING 
SYSTEM  .  B-l 

B. l  System  Context  .  B-5 

B.2  Fuel  Level  Monitoring  ^tem  Dependency  Graph  .  B-6 

B.3  mode_Class_In_Operation .  B-7 

B.3.1  Class  Interface  .  B-7 

B.3.2  Encapsulated  Information .  B-7 

B.3.3  'Baceability .  B-8 

B.4  class_Fuel_'Ihnk .  B-9 

B.4.1  Class  Interface  .  B-9 

B.4.1.1  NAT  Relation  .  B-10 

B.4.2  Encapsulated  Information .  B-10 

B.4.2.1  Input  Variables .  B-10 

B.4.23  IN  Relation .  B-11 

B.43  ll-aceabiliQr .  B-12 

B.5  class_Pump .  B-13 

B.5.1  Class  Interface .  B-13 


Cooteatt 


BS.2  Encapsulated  Information .  B-13 

B.5.2.1  REQ  Relation .  B-13 

B.5^.2  Output  Variables .  B-14 

B.523  OUT  Relation .  B-14 

B.53  T-acMbility .  B-14 

B.6  dassjnme  .  B-15 

B.6.1  Qass  Interface .  B-15 

B.6.2  Encapsulated  Information .  B-15 

B.6.2.1  Input  Variables .  B-15 

B.62.2  IN  Relation .  B-15 

B.6J  Haceability .  B-15 

B.7  class^Operator .  B-16 

B.7.1  Class  Interface  .  B-16 

B.7.2  Encapsulated  Information .  B-16 

B.7.3  li-aceabiUty .  B-16 

B.8  class_Operator_Communication .  B-17 

B.8.1  Class  Interface  .  B-17 

B.8.2  Encapsulated  Information .  B-17 

B.8.2.1  REQ  Relation .  B-18 

B.82.2  Output  Variables .  B-21 

B.8.23  OUT  Relation .  B-21 

B.8.3  IfaceabiliOr .  B-22 

B.9  class_Switch  .  B-23 

B.9.1  Qass  Interface .  B-23 

B.9.2  Encapsulated  Information .  B-23 

B.9.2.1  Input  Variables .  B-23 

B.9.2.2  IN  Relation .  B-24 


B-24 


B. 93  'Baceabili^  — 

B.10  Safety  Requirements .  B-24 

B.11  Security  Requirements  .  B-25 

B. 12  Other  Requirements . B-25 

APPENDK  B  INDEX . B-26 

APPENDIX  C.  Core  MAPPING  TO  DOD-STD-2167A .  C-1 

C. 1  Introduction . C-1 

C2  Software  Requirements  Specification .  C-3 

C2.1  SRS  Faragraf^  3.1:  CSCI  External  Interface  Requirements  .  C-3 

C. 2.2  SRS  Paragraph  3.2:  CSCI  Capability  Requirements .  C-3 

C.23  SRS  Paragraph  3.2j::  (Capability  Name  and  Project-Unique  Identifier) _  04 

C.2.4  SRS  Paragraph  3.3.:  CSCI  Internal  Interfaces .  C-4 

C.Z5  SRS  Paragraph  3.4.:  CSCI  Data  Element  Requirements  .  C-4 

C.2.6  SRS  Paragraph  3.5.:  Adaptation  Requirements .  C-4 

C.2.7  SRS  Paragraph  3.5.1.:  Installation-Dependent  Data .  04 

0.2.S  SRS  Paragraph  3.5.2.:  Operational  I^ameters .  C-4 

UST  OF  ABBREVIATIONS  AND  ACRONYMS .  Abb-1 

GLOSSARY .  Glo-1 

REFERENCES . Ref-1 

BIBLIOGRAPHY .  Bib-1 


INDEX 


Ind-1 


FIGURES 


Figure  2-1.  System  Viewed  as  a  Black  Box .  2-6 

Figure  2-2.  System  Viewed  With  Input  and  Output  . .  2-6 

Figure  2-3.  The  Behavioral  Model  Relations .  2-7 

Hgure  2-4.  Graphic  Depiction  of  the  Depends-on  Relation .  2-13 

Figure  2-5.  Canonical  Allocation  of  Behavioral  Model  to  Qasses .  2-lS 

Figure  3-1.  Fuel  Level  Monitoring  System  Pump  and  Thnk  Configuration  (Front  View)  .  3-2 

Figure  4-1.  Representation  of  CoRE’s  Functional  View .  4-2 

Figure  4-2.  Example  of  a  Mode  Transition  Diagram .  4-7 

Figure  4-3.  The  Semantics  of  INMODE,  EXITED,  and  ENTERED .  4-9 

Figure  4-4.  Time  Line  for  Periodic  Controlled  Variable  Process .  4-14 

Figure  4-5.  Time  Line  for  Demand  Controlled  Variable  Process .  4-15 

Figure  5-1.  Pump  Entity  and  Attributes  Example  .  5-2 

Rgure5-2.  Entity-Relationship  Diagram  Notation .  5-3 

Hgure5-3.  Generalization/Specialization  Entity-Relationship  Diagram  Notation .  5-4 

Hgure5-4.  Aggregation  Entity-Relationship  Diagram  Notation .  5-4 

Rgure5-5.  Application-Specific  Relationship  Notation .  5-5 

Figure  5-6.  Class  Structuring  Notation  .  5-7 

Figure  5-7.  Representation  of  an  Overview  of  a  Specification  Using  a  Context  Diagram  .  5-7 

Figure  5-8.  Dependency  Graph  Notation  .  5-8 

Figure  5-9.  Class  Structuring  Leveling  Diagrams .  5-8 

Hgure5-10.  Class  Interface  Notation .  5-10 

Figure  5-11.  Encapsulation  Structure  Notation  .  5-11 


Figure  S-12.  class_Eiigine  Diagram .  5-11 

Rgure5-13.  dass_Engine  Dia^am  With  Objects . .  5-12 

Rgure5-14.  Inheritance  Notation .  5-14 

Figure  5-15.  Qass  Model  Notation  Summary .  5-15 

Figure  6-1.  Ck}RE  Activities  and  Products .  6-2 

Rgure  6-2.  Results  of  Steps  1  and  2 .  6-8 

Rgure  6-3.  Results  of  Steps  3  and  4  . .  6-9 

Rgure  6-4.  Result  of  Steps  5  and  6 .  6-10 

Rgure  6-5.  Results  of  Steps  7  and  8 .  6-10 

Rgure  7-1.  Information  Model  for  the  Fuel  Level  Monitoring  System .  7-7 

Figure  7-2.  Weapon  and  Ihrget  Constraint .  7-9 

Figure  8-1.  Controlled  Variable  Overview  for  con_Low_Alarm .  8-8 

Figure  8-2.  Using  a  Mode  Transition  Diagram  to  Represent  mode_class_In_Operation  .  8-13 

Figure  9-1.  Partial  Definitions  of  class_FuelJIhnk .  9-5 

Figure  9-2.  Mode  Class  Interface  Example .  9-7 

Rgure  9-3.  Dependency  Graph  for  Operator  Interface .  9-9 

Figure  9-4.  Generalization/Specialization  Example .  9-11 

Figure  9-5.  Fuel  Level  Monitoring  System  Dependency  Graph .  9-13 

Figure  11-1.  IN  Relation  for  in_Diff_Press .  11-4 

Figure  11-2.  Accuracy  Specification  for  in_Diff_Press .  11-5 

Figure  B-1.  Fuel  Level  Monitoring  System:  Context  Diagram  .  B-5 

Figure  B-2.  Fuel  Level  Monitoring  System  Dependency  Graph .  B-6 


Figure  B-3.  Fbel  Level  Monitoring  System  Pump  and  link  Configuration  (Front  \fiew)  .  B-9 


TABLES 


Spedficatioa  Properties  Versus  Core  Medianism .  2-4 

'!Qible4-l.  Template  for  Monitored  and  Controlled  Viable  Definitions .  4-3 

Ibble  4-2.  Using  a  l^le  to  Represent  the  Mode  Machine  In_Operation .  4-8 

'Ihble4-3.  Format  of  a  Condition 'Rible .  4-10 

Ihble  4-4.  Example  of  a  Condition  Ihble .  4-11 

'lhble4-5.  Format  of  an  Event  Ikble  .  4-11 

'Dible4-6.  Example  of  an  Event  Ihble .  4-12 

'Ikble4-7.  Format  of  a  Selector  Thble  .  4-12 

'Ihble4-8.  Example  of  a  Selector  Ikble  .  4-12 

Ikble  4-9.  Ibmplate  for  a  Controlled  Variable  with  Periodic  Scheduling  Constraints  . . .  4-15 

Ihble  4-10.  Ibmplate  for  a  Controlled  Variable  \^th  Demand  Scheduling  Constraints  . .  4-16 

Thble  5-1.  Entity  Ibmplate .  5-2 

'Bible  5-2.  Partial  Attribute  Matrix  for  Fuel  Level  Monitoring  System .  5-3 

'Eible5-3.  Class  Ibmplate  .  5-5 

1kble54.  superclass_A'Ibmplate .  5-12 

1hble5-5.  class_BIbmplate  .  5-13 

111^0  5-6.  class_C1bmplate  .  5-13 

Ihble  5-7.  Class  Template  Summary .  5-14 

Bible  7-1.  Sample  Fuel  Monitoring  System  Attributes  .  7-4 

1hble7-2.  Sample  Definition  of  an  Enumerated  Attribute .  74 

'Bible  7-3.  Sample  Definition  of  a  Numeric  Attribute .  7-5 

'Bd>le74.  Sample  Fuel  Level  Monitoring  System  Entities  and  Attributes  .  7-6 


'Bd)lc7-5.  Ricl  Level  Monitoring  System  Attribute  Matrix  .  7-8 

TW)le  8-1.  Definition  of  Enumerated  Environmental  Variable .  8-6 

*015^8-2.  Definition  of  Numeric  Environmental  Viable .  8-6 

'Bible  10-1.  Event  Ibble  Example  (Incomplete) .  10-S 

lbblelO-2.  Event  Ibble  Examfde  (Completed)  .  10-5 

Ibbie  10-3.  Initial  Condition  *01610  Example  (Incomplete) .  10-7 

Ibble  10-4.  Condition  Ibble  Example  (Completed) .  10-7 

Ibble  10-5.  Initiation  and  Ibrmination  Events  for  con_Status  .  10-8 

Ibble  11-1.  Input  and  Output  Variable  Ibmplate .  11-3 

Ibble  11-2.  Sample  Definition  of  Input  Variable  Diff_Prcss .  11-3 

Ibble  11-3.  Sample  Definition  of  Output  \^iable  Shutdown  Signal .  11-3 

Ibble  11-4.  Sample  OUT  Relation  for  Controlled  Variable  con_Shutdown_Relay .  11-6 

Ibble  11-5.  Sample  Iblerance  and  Delay  for  Controlled  Variable  con_Shutdown_Relay  .  11-6 

Ibble  C-1.  Relationship  of  CoRE.  Specification  Elements  to  the 

Software  Requirements  Spedfication  .  C-1 

Ibble  C-2.  Example  of  CSCl  System  States  Mapping  to  Capabilities .  C-3 


This  page  intentionalfy  blank. 


ACKNOWLEDGMENTS 


The  following  contributors  have  been  instrumental  in  develof^  the  CoRE  method  and  this 
guidebook: 

•  Stuart  R.  Faulk,  James  Kirt^,  Jr.,  Lisa  Hnneran,  and  Assad  Moini  authored  this  version  of  the 
guidebook. 

•  Paul  \il^d  has  worked  as  both  consultant  and  reviewer  on  the  CoRE  project  He  has  been 
instrumental  in  helping  develop  CoRE's  class  model. 

•  John  Brackett  assisted  in  identifying  the  problems  CoRE  addresses  and  has  provided  excellent 
reviews  of  this  guidebook. 

•  Gi^  Cox,  Doug  Smith,  and  Steve  ^T^^rtik  contributed  to  the  development  of  CoRE. 

•  Much  of  what  is  good  in  this  guidebook  is  due  to  excellent  reviews  provided  by  John  Bradcett 
Paul  Qements,  Ron  Darner,  Howard  Likins,  \^uioe  Mall,  David  Pamas,  and  Paul  Ward. 

•  The  production  quality  is  due  to  the  tedmical  editing  of  Mary  Mallonee,  word  jvocessing  by 
Debbie  Morgan  and  Deborah  Upeni,  and  dean  proofipg  by  Betfy  Leach  and  Tina  Medina. 


This  page  irUentimaJfyt^  blank. 


1.  INTRODUCTION 


The  Consortium  Requirements  Engineering  (CoRE)  method  is  a  method  for  cajmirii^  specifying, 
and  analyzing  software  requirements.  The  Consortium  has  worked  with  industrial  develops  of 
real-time  and  embedded  systems  to  identify  their  problems  and  to  provide  a  method  that  address¬ 
es  their  needs.  CoRE  supports  the  development  of  precise,  testable  specificaticms  that  are  demcm- 
strably  comiriete  and  consistent  CoRE  also  supports  key  process  issues,  sudi  as  managing  dianging 
requirements  and  reuse.  CoRE  is  a  single  coherent  requirements  method  that: 

•  haegmies  O^eet-OriaaedtmdFbrmai  Afodlsb.  Behavioral^  requirements  in  CoRE  are  written 
in  terms  of  two  underlying  models:  the  behavioral  model  and  the  class  mode.  The  behavioral 
model  provides  a  standard  structure  for  analyzing  and  capturing  behavioral  requirements 
(i.e.,  w^t  the  software  must  do)  in  a  form  that  is  is  precise,  analyzable,  and  testable.  The  dass 
model  larovides  fadlides  for  organizing  a  CoRE  specification  into  parts;  it  provides  facilities 
suf^rting  change  management,  reuse,  and  concurrent  development.  These  models  are 
integrated  in  a  single  CoRE  spedfication. 

•  Intfgntes  Graphical  and  ISgoroiis  Spec^ications.  A  key  goal  of  the  method  is  to  improve 
communication  among  the  parties  involved  in  requirements  engineering.  CoRE  provides  a 
graphic  representation  that  helps  all  parties,  customers,  engineers,  designers,  and  program¬ 
mers  grasp  essential  relationships  among  system  components.  CoRE  also  p-ovides  a  rigorous 
underlying  model  for  capturing  detailed  behavioral,  timing,  and  accuracy  constraints.  This  rig¬ 
orous  model  allows  you  to  develop  requirements  that  are  pedse,  unambiguous,  testable,  and 
denmnstrably  complete  and  consistent  CoRE  povides  a  consistent  interpetation  of  both 
graiirfuca]  and  rigorous  notations  so  th^  combine  smoothly  in  a  single  spe^cation. 

•  VsesEjdsdngSliUsaniNotations.  The  language  used  to  specify  requirements  in  CoRE  is  based 

on  familiar  concepts  and  odsting  notations.  You  can  CoRE  using  basic  concepts  familiar 

to  pogrammers  and  others  writing  requirements,  e.g.,  events,  Boolean  oqx'essions,  and  state 
machines.  Although  CoRE  is  based  on  an  underlying  nuthemadcal  mode,  just  as  pogram- 
ming  languages  are  based  on  formal  models,  CoRE  can  be  api^ed  wiAout  a  detailed 
understanding  of  formalisms. 

•  Avoids  Premature  Des^  Dedans.  CoRE  allows  you  to  spedfy  requirements  without 
pematurely  specifying  design  or  implementation  detdls.  CoRE  describe  required  behavior 
in  terms  of  relations  that  the  softwiu'e  must  nuuntain  between  quantities  that  the  software 
monitors  and  those  it  controls.  This  allows  you  to  spedfy  what  the  software  must  do  without 
having  to  povide  an  algorithm  or  detailed  design. 

1.  SometiioescanedfwietkxiaIraqaireineiiUTIii*giiidebo(AnwrvwUietitecfthetennfuiictk»toreftf tomathematiciJ 

functions  and  iisM  bdinm  to  deteribe  the  sc^twtre’i  vis3>Ie  effects. 


1.  latroducUon 


•  frovUks  GmdaicA.  Ute  GoRE  behavioral  tnodel  provides  practical  guidance  in  didtiug  software 
reqiarements,  developing  a  requiremeius  specification,  and  analyziqg  the  ^pedficatkxt  for 
oonqjletaiess  and  consistency.  The  behavioral  model  defines  exac^  what  requireinents  information 
must  be  captured,  and  in  what  form,  to  develop  a  oonqilete  and  consistent  ^)ecificatkxL 

1.1  PURPOSE  OF  THIS  GUIDEBOOK 

This  guidebook  provides  a  detailed  guide  to  the  practice  of  CoRE.  It  is  intended  as  an  engineering 
handbook  that  ^tems  and  software  engineers  can  use  as  a  reference  when  aj^lying  the  CoRE 
method.  It  describes  the  following: 

•  The  goals  and  benefits  of  the  CoRE  method 

•  The  underfying  concepts  and  princiides  used  to  develop  rigorous  requirements  spedfications 
in  Core 

•  The  set  of  notations  and  specification  tedhniques  needed  to  write  a  CoRE  spedfication 

•  A  complete  requirements  development  process  starting  with  system-level  requirements  as 
input  and  endii^  with  a  software  requirements  specification  as  output 

•  Heuristics  for  applying  spedfic  techniques  to  accomplish  your  spedfication  goals,  such  as 
reuse  or  change  management 

•  Criteria  and  a  process  for  diecldng  a  CoRE  spedfication  for  completeness  and  consistency 

•  Illustration  of  the  tediniques  and  heuristics  through  a  common  example — the  Fuel  Level 
Monitoring  System  (FLMS). 

This  guidebook  is  arranged  for  self-study.  Read  front  to  bade,  this  guidebook  presents  the  CoRE 
method  as  a  logical  progression  of  topics  be^nning  with  basic  concepts  and  notations. 

12  INTENDED  AUDIENCE 

This  guidebook  is  intended  for  engineers  developng  the  requirements  for  production-quality 
software. 

Eaqperience  in  the  development  of  real-time  systems,  particularly  real-time  system  requirements,  is 
ne^ed  to  fully  understand  the  details  of  CoRE.  All  of  the  notations  spedfic  to  CoRE  and  their  use 
are  described  in  this  guidebook.  This  guidebook  assumes  only  a  basic  knowledge  of  the  following 
concepts: 

•  Hnite  state  madiines 

•  Sets 

•  Boolean  e]q>ressions 

How  these  concepts  are  used  to  represent  requirements  in  CoRE  is  fiilly  desoibed  in  this  guidebook. 


13  SCOPE  OF  THE  METHOD  AND  GUIDEBOOK 


The  versiOD  of  CoRE  described  in  this  guidebook  supped  specification  of  requirements  for  real-time 
embedded  ^tems.  CoRE  {vovides  a  behavioral  model  of  embedded  system  behavior;  this  is 
described  in  detail  in  Section  2.  The  behavioral  model  addresses  behavioral  requirements,  induding 
those  for  predsion,  timing,  and  accuracy. 

Software  requirements  that  are  most  easily  captured  using  CoRE  are  those  with  properties  that  are 
consistent  with  the  CoRE  behavioral  model.  OsRE  expresses  requirements  by  defining  the  relation¬ 
ships  the  software  must  maintain  between  dianges  in  the  divironment  that  the  software  monitors  and 
the  required  effect  on  the  devices,  disj^ys,  and  other  observable  quantities  that  the  software  controls. 
These  are  properties  typical  of  embedded  control  systems,  su^  as  avionics  and  process  control 
^ems. 

The  CoRE  guidebook  currently  does  not  provide  e]q)lidt  guidance  for  modeling  complex  data 
relationships  and  data,  transactions.  Thus,  this  guidebook  does  not  directly  address  parts  of  aj^ca- 
titms  whose  {ximary  purpose  is  maintaining  complex  databases  and  imjdementing  data  transactions. 
These  include  some  data-intensive  command,  control,  communications,  and  intelligence  (C^I)  and 
information  management  systems.  Subsequent  Consortium  products  will  provide  methods  and 
guidance  for  applying  CoRE  to  C^I  systems. 

The  scope  of  this  guidebook  includes  all  of  the  activities  and  products  necessary  for  developing  a 
detailed  software  requirements  specification  from  system  requirements.  This  guidebook  addresses 
behavioral  requirements  (sometimes  called  functional  requirements),  timing  constraints  (induding 
performance  requirements),  accuracy  constraints,  and  software  and  hardware  interfaces.  It  does  not 
directly  address  some  nonfonaional  requirements,  such  as  maintainability  or  capadty  requirements. 
However,  your  current  approach  to  these  requirements  can  be  used  with  CoRE. 

1.4  ORGANIZATION  OF  THE  GUIDEBOOK 

This  guidebook  is  structured  to  support  self-stu^  and  for  use  as  a  reference.  In  particular,  it  is 
organized  so  it  presents  a  logical  progression  of  topics  and  a  logical  sequence  of  aedyities  when  read 
from  front  to  back  as  follows: 

•  Introduction  and  Baclsground.  Sections  1,  2,  4,  and  5  provide  the  introductory  material 
necessary  to  understand  CoRE’s  purpose,  to  gain  an  overall  perspective  of  the  way  CoRE 
models  requirements,  and  to  understand  the  notational  conventions  used  throughout  the 
guidebook. 

•  Example,  Section  3  introduces  the  sample  problem,  the  ELMS,  that  will  be  used  throughout 
the  guidebook  to  illustrate  CoRE  concepts.  A  more  detailed  p-ose  spedfication  is  given  in 
Appendix  A,  and  a  oomf^ete  spedfication  of  the  ELMS  is  provided  in  Appendix  B.  The 
detailed  process  sections  (Sections  7  through  12)  discuss  pieces  of  the  spedfication  in  detail 
and  provide  rationale  for  their  construction. 

•  CoRE  Conee/os  and  Notation.  Sections  4  and  5  describe  the  underlying  concepts,  syntax,  and 
semantics  for  representing  the  CoRE  behavioral  model  and  CoRE  dass  model. 

•  CoRE  Process  and  Activities.  Sections  6  through  1 1  describe  the  CoRE  process  and  give  detailed 
guidance  for  each  of  the  CoRE  activities.  Section  6  gives  an  overview  of  the  CoRE  process 


1.  Introduction 


from  both  an  idealized  and  a  practical  perspective.  Each  of  the  subsequent  sections  describes 
one  of  the  CoRE  activities  in  detail. 

•  yOiafyzu^  and  Vnng  a  CoRE  Specification.  Section  12  of  the  guidebook  describes  an  overall 
process  for  analyzing  completeness  and  consistency  of  a  CoRE  spedfication.  This  section 
discusses  the  detailed  analyses  provided  in  Sections  7  through  11  in  the  context  of  the  overall 
process. 

USING  THIS  GUIDEBOOK 

This  guidebook  is  fnrimarily  intended  as  a  reference  for  practitioners  of  the  CoRE  method,  but  it  can 
also  be  used,  with  supporting  documentation,  as  a  tutorial. 

•  Readingfor  an  Ovendew.  Sections  1, 2,  and  6  provide  a  oomi^ete  overview  of  the  CoRE  method. 
Section  1  describes  the  intended  use  of  CoRE  and  the  role  of  this  guidebook.  Section  2  gives 
an  overview  of  the  key  ideas  behind  the  CoRE  method,  induding  the  standard  models  for  cap¬ 
turing  requirements.  Section  6  gives  an  overview  of  the  CoRE  process,  induding  the  inputs, 
outputs,  and  key  dedsions  in  each  CoRE  activity. 

•  Usii^  dte  Gwddiook  as  a  Rtfierence.  Sections  4  and  5  provide  detailed  discussions  of  the 
notations  used  to  represent  the  behavioral  and  class  models,  respectively.  Sections  6  through 
11  provide  a  detailed  guide  to  apf^ng  the  CoRE  method.  Use  Section  6  to  get  an  overview 
of  Ae  process  and  understand  wMdi  detailed  process  section  applies.  Use  the  detailed  process 
section  to  understand  a  particular  CoRE  activity.  Eadi  of  the  detailed  sections  describes  (for 
a  given  CoRE  activity)  the  inputs  needed,  the  work  products  produced,  the  detailed 
procedures,  use  of  CoRE  notation,  and  applicable  heuristics. 

•  Using  the  Guidebook  for  a  TUtoriaL  As  a  tutorial  on  the  CoRE  method,  this  guidebook  is 
designed  to  be  read  from  front  to  back.  Section  2  introduces  ail  of  the  important  CoRE  con¬ 
cepts,  induding  the  standard  model  for  spedfying  CoRE  requirements.  Section  3  deso’ibes 
an  example  of  an  application;  this  example  is  used  throughout  the  text  to  illustrate  the  method. 
Sections  4  and  5  desoibe  the  CoRE  notations  and  their  use.  Section  6  gives  an  overview  of  the 
CoRE  process  and  summarizes  the  key  inputs,  outputs,  and  dedsions  made  in  each  CoRE 
activity.  The  subsequent  sections  then  describe  the  activities  in  detail. 

1.6  TYPOGRAPHIC  CONVENTIONS 

This  guidebook  uses  the  following  typographic  conventions: 


Serif  font .  General  presentation  of  information. 

Italicized  serif  font .  Mathematical  expressions  and  publication  titles. 

Boldfiiced  serif  font . Section  headings  and  emphasis.  Section  headings  of  a 

CoRE  template. 


Boldfaced  italicized  saif  font 


Run-in  headings  in  bulleted  lists  and  low-level  titles  in  the 
process  section. 


Sans  serif  font 


triable  names,  repressions,  or  mode  names  from  a  CoRE 
example  in  the  text.  Spedfre  parameters  of  a  CoRE 
spedfication  in  the  text. 


Italicized  sans  serif  font  .  Vi^thin  commands,  generic  values  to  be  supplied  by  the 

user,  in  a  CoRE  examine  in  the  text,  and  in  a  CoRE  term. 
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This  intentionalfy  left  Monk. 
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2.  THE  Core  MODELS 


Core  is  a  method  for  capturing,  spedfying,  and  analyzing  real-time  software  requirements.  CoRE 
{MTOvides  a  step-by-step  apf^roadi,  including  prindjdes  and  guidelines,  for  proceeding  from  ^tern- 
level  requirements  to  a  predse,  testable  softie  requirements  specification.  A  CoRE  specification 
captures  requirements  in  terms  familiar  to  the  customer  (i.e.,  phydcal  quantities  monitored  and  con¬ 
trolled  the  software)  so  issues  of  customer  validation  are  a^essed  early  in  the  development  fvo- 
cess.  A  CoRE  requirements  specification  {divides  a  {sedse  description  of  the  range  of  acceptable 
software  behaviors;  thus,  a  CoRE  specification  ix^ovides  a  common  vehide  for  communicating  re¬ 
quirements  among  developers  or  contractors,  acquisition  managers,  and  users.  A  CoRE  specification 
serves  as  both  the  test-to  and  design-to  specification,  ensuring  that  designers  and  testers  are  working 
to  the  same  requirements.  A  CoRE  specification  is  also  sufBdmtly  rigorous  that  the  requirements 
can  be  analyzed  for  completeness  and  condsten^.  This  helps  the  developer  ensure  that  requirements 
errors  are  identified  and  corrected  early  in  development. 

This  guidebook  provides  a  description  of  all  the  CoRE  activities  and  the  order  in  wiiidiyou  are  most 
likely  to  pursue  those  activities.  CoRE  provides  evaluation  criteria  for  dedding  when  an  activiQr  is 
complete.  Each  CoRE  activity  is  defined  by  its  entrance  criteria,  subactivities,  evaluation  criteria,  and 
exit  criteria. 

A  CoRE  specification  is  written  in  terms  of  two  underlying  models:  the  behavioral  model  and  the  dass 
model: 

•  The  behavioral  model  provides  a  standard  structure  for  analyzing  and  capturing  the 
behavioral  requirements  of  an  embedded  system;  i.e.,  you  specify  ^^t  the  software  must  do 
in  terms  of  the  behavioral  model.  The  behavioral  model  provides  the  medianisms  you  need 
to  spedfy  requirements  that  are  predse,  testable,  comf^ete,  and  consistent. 

•  The  dass  model  provides  a  set  of  fadiities  for  padaging  the  information  in  a  CoRE 
spedfication;  i.e.,  you  organize  the  specification  as  a  set  of  dasses.  The  dass  model  allows  you 
to  divide  the  spedfication  into  relatively  independent  parts  and  control  the  relationships 
between  the'  parts.  The  class  model  provides  the  medianisms  to  manage  requirements 
dianges,  create  reusaUe  requirements,  and  develop  parts  of  the  software  ^stem  in  parallel. 

The  two  models  are  integrated  in  a  single  work  product,  a  software  requirements  spedfication.  The 
behavioral  model  defines  the  required  behavior,  i.e.,  what  the  software  must  do.  The  dass  model 
guides  the  basic  organization  of  the  specification. 

This  section  desoibes  the  underlying  CoRE  models  and  how  they  address  specific  requirements 
issues,  sudi  as  diange  management  and  the  develo{»nent  of  com|dete  and  consistent  specifications. 
After  reading  this  section,  you  should  tmderstand: 
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•  The  major  steps  of  the  CoRE  process  (Section  2.1) 

•  The  purpose  and  objectives  of  the  CoRE  models  (Section  2.2) 

•  The  Core  behavioral  model  for  real-time  software  behavior,  how  behavioral  requirements 
are  captured  in  terms  of  the  model,  and  how  the  behavioral  model  supports  analysis  of 
completeness  and  consistency  (Section  2.3) 

•  The  relationship  between  the  CoRE  behavioral  model  and  the  class  model,  how  classes  are 
used  to  manage  complexity  and  change,  and  how  the  behavioral  model  guides  you  in  choosing 
and  defining  classes  (Section  2.4) 

•  How  the  behavioral  and  class  models  are  integrated  in  a  CoRE  specification  (Section  2.4.2) 

2.1  Core  process  overview 

The  CoRE  process  describes  a  sequence  of  activities  that  you  follow  to  develop  a  CoRE  requirements 
spedfication.  The  CoRE  process  is  driven  by  two  concerns.  The  first  concern  is  the  step-by-step  con¬ 
struction  of  a  required  behavior  specification  in  terms  of  the  CoRE  behavioral  model.  The  goal  is  to 
develop  a  complete  and  consistent  description  of  the  required  behavior.  The  second  concern  is  the 
packaging  of  the  specification  in  elements  of  the  class  model.  This  aspect  of  the  process  satisfies  pack¬ 
aging  goals,  such  as  change  management  and  reuse.  Because  padcaging  and  specification  activities 
overlap  in  time,  the  threads  of  these  activities  are  intertwined  in  the  CoRE  process. 

The  input  to  the  CoRE  process  is  some  form  of  system  requirements.  The  output  of  the  CoRE  process 
is  a  complete  spedfication  of  the  software  requirements  (i.e.,  suitable  input  for  a  software  design  pro¬ 
cess).  A  complete  overview  of  the  intervening  sequence  of  CoRE  activities  and  products  is  given  in 
Section  6;  in  brief,  these  activities  are: 

•  Identify  the  environmental  quantities  with  which  the  software  interacts  and  the  constraints 
among  such  quantities. 

•  Identify  the  software  boundary  by  spedfying  the  enviromnental  quantities  that  the  software 
must  track  or  affect. 

•  Package  the  environmental  quantities  among  a  set  of  CoRE  classes  and  relationships. 

•  Define  the  software  behavior,  timing,  and  accuracy  constraints. 

•  Define  the  software  inputs  and  outputs. 

The  first  two  steps  initiate  definition  of  the  behavioral  model  by  establishing  which  environmental 
quantities  the  software  monitors  and  controls  and  the  basic  relationships  the  software  must  imple¬ 
ment  among  them.  The  third  step  determines  how  the  elements  of  the  behavioral  model  should  be 
allocated  to  CoRE  classes  and  the  relationships  among  the  dasses.  The  final  steps  complete  the  class 
definitions  by  filling  in  the  details  of  the  parts  of  the  behavioral  model  allocated  to  each  class. 

2.2  PURPOSE  OF  THE  CoRE  MODELS 

The  CoRE  method,  including  the  use  of  the  underlying  models,  has  been  developed  to  address  specific 
problems  of  industrial  developers  of  embedded  software.  This  section  describes  the  issues  Col^  has 
been  developed  to  address  and  how  the  CoRE  models  help  address  these  issues. 
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2L2.1  Rationale  FOR  THE  Core  Approach 

In  creating  CoRE,  the  Consortium  met  with  developers  to  identify  their  problems  with  current 
requirements  methods  and  tools.  These  representatives  helped  define  a  set  of  requirements  that  the 
Core  method  should  meet.  These  requirements  are  sununarized  below: 

•  Critical  Applications.  The  method  must  support  the  development  of  precise,  testable 
specifications  for  real-time  embedded  systems. 

•  CkangingRequiranents.  The  method  must  support  developing  requirements  spedfications  that 
are  easy  to  change  throughout  the  software  Itfe  (^e.  When  requirements  charge,  it  must  be 
easy  to  tell  which  parts  of  the  requirements  spedfication  and  other  work  products  are  affected. 

•  Audience.  The  method  must  support  the  development  of  requirements  spedfications  that  are 
understandable  and  useful  to  the  spedfication’s  entire  audience,  includi^  systems  engineers, 
hardware  engineers,  and  software  ei^neers.  It  must  support  the  ability  to  derive 
customer-oriented  views  of  software  requirements. 

•  System  Interface.  The  method  must  support  the  delineation  of  system  boundaries  and  the 
predse  specification  of  system  interfaces  that  concern  the  software.  It  must  support  descrip¬ 
tions  of  both  the  system  and  the  environment  in  whidi  it  operates,  including  other  systems 
under  development. 

•  S^aration  of  Concerns.  The  method  must  support  the  definition  of  requirements  as  a  set  of 
distinct  and  relatively  independent  parts.  It  must  support  localizing  requirements  that  are 
fuzzy,  incomplete,  or  defined  at  different  levels  of  detail  and  allow  work  to  proceed 
independently  on  distinct  parts. 

•  Derivation  Ftom  System  Requirements.  The  method  must  include  guidelines  and  examples  of 
required  inputs  for  the  software  requirements  process  and  the  form  sudi  inputs  from  systems 
engineering  must  take. 

•  Notudgoridimic  Spec^ication.  The  method  must  allow  nonalgorithmic  specification  of 
requirements  when  a  specific  algorithm  is  not  actually  required. 

•  Consi^u Requirements.  The  method  must  define  what  makes  a  set  of  requirements  consistent 
(unambiguous).  It  must  include  principles,  guidelines,  and  techniques  for  determining  wheth¬ 
er  requirements  are  internally  consistent  and  for  keeping  these  requirements  internally 
consistent  after  they  have  been  changed. 

•  Complete  Requirements.  It  must  be  possible  to  determine  where  the  requirements  spedfication 
is  internally  incomplete.  The  method  must  permit  definition  and  use  of  incomplete  require¬ 
ments.  For  example,  the  method  must  allow  detailing  and  diecking  of  one  part  of  the 
requirements  before  another  is  complete. 

The  CoRE  models  have  been  developed  so  that  these  and  other  requirements  concerns  can  be 
addressed  in  a  CoRE  spedfication. 

2.2.2  Purpose  of  the  Behavioral  and  Class  Models 

The  CoRE  behavioral  model  provides  a  standard  structure  for  analyzing  and  capturing  the  behavioral 
requirements  for  real-time  embedded  systems.  The  CoRE  behavioral  model  is  standardized  in  the 
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sense  that  every  CoRE  specification  captures  behavioral  requirements  using  the  same  basic  structures 
and  relationships,  i.e.,  as  a  set  of  relationships  between  the  quantities  the  software  system  monitors 
and  controls.  This  standardized  approach  allows  CoRE  to  provide  a  well-defined  sequence  of  activi¬ 
ties  and  checks  that  proceeds  systematically  from  the  early  analysis  of  what  the  software  controls  to 
a  complete  specification  of  required  behavior.  The  behavioral  model  also  provides  mechanisms  for 
e3q}re$siiig  the  behavioral  requirements  rigorously  so  the  resulting  spedfication  is  precise  and 
testable. 

Because  a  CoRE  spedfication  is  written  in  a  rigorous  language,  there  are  systematic  procedures  for 
determining  the  consistency  and  completeness.  The  use  of  mathematical  expressions  also  helj^  avoid 
overspecifying  the  requirements.  Defining  required  behavior  in  terms  of  operations  or  algorithms  of¬ 
ten  necessitates  introducing  dedsions  that  are  not  actually  requirements  (e.g.,  the  order  of  operations 
and  how  one  operation  interacts  with  another).  The  designer  cannot  determine  which  parts  of  the 
model  actually  reflect  the  customer’s  requirements  and  w4uch  are  artifacts  of  the  construction.  CoRE 
spedfications  capture  only  what  the  software  must  do,  not  how  to  do  it. 

A  CoRE  spedfication  is  structured,  using  object-oriented  terminology,  as  a  set  of  class  definitions  in 
which  a  class  is  a  template  for  an  object.  The  CoRE  dass  is  the  basic  mechanism  for  dividing  the  sped¬ 
fication  into  parts  and  controlling  the  relationships  among  different  parts  of  the  specification.  The  set 
of  classes  and  their  relationships  in  a  CoRE  spedfication  are  collectively  called  the  class  model. 

t 

It 

While  the  behavioral  model  addresses  properties  of  the  behavioral  reqtiirements,  such  as 
completeness,  consistency,  predsion,  and  testability,  the  class  model  addresses  packaging  concerns. 
Fading  concerns  are  properties  of  a  specification  that  result  from  the  way  information  is  parti¬ 
tioned.  Packaging  concerns  include  ease  of  change,  ease  of  use,  encapsulation  of  fuzzy  requirements, 
and  reusability.  For  example,  if  a  requirement  that  is  likely  to  change  is  encapsulated  in  a  CoRE  dass 
definition,  only  that  class  definition  will  change  if  the  requirement  changes.  Ihble  2-1  summarizes  the 
properties  supported  by  each  of  the  CoRE  models. 


Ikble  2-1.  Spedfication  Properties  Versus  CoRE  Mechanism 


Specification  Properties 

Supporting  CoRE  Medianism 

Desired  Factional  Requirements  Properties 

•  Complete 

•  Consistent 

•  Precise 

•  Unambiguous 

•  Tbstable 

•  Behavioral  model 
(Four-variable  model) 

Desired  Packaging  Properties 

•  Easy  to  change 

•  Encapsulates  fuzzy  requirements 

•  Allows  asynchronous  development 

•  Readable 

•  Reusable 

•  Qass  model 
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The  dass  and  behavioral  models  are  integrated  into  a  single  requirements  specification  in  udiich  the 
information  in  the  behavioral  model  is  partitioned  among  a  set  of  CoRE  dasses.  The  dasses  make 
up  the  organization.  You  determine  sudi  characteristics  as  the  number  of  dasses,  what  information 
is  hidden,  and  whidi  parts  of  the  model  are  allocated  to  the  same  dass  based  on  your  overall  goals  for 
the  requirements  structure.  You  can  address  many  of  the  issues  of  readability,  reuse,  and  change 
management  by  judidous  packaging. 

Separating  the  behavioral  and  class  models  is  one  of  the  key  features  of  CoRE.  The  separation  allows 
you  to  make  and  subsequently  change  dedsions  about  packaging  issues  with  limited  and  controlled 
effect  on  the  meaning  of  the  specification.  The  CoRE  dass  model  allows  you  to  write  the  specification 
to  have  desirable  properties  like  ease  of  diange  without  designing  the  software. 

23  THE  Core  BEHAVIORAL  MODEL 

The  Core  behavioral  model  is  based  on  a  four-variable  model  developed  by  Famas  and  Madey 
(1990)  and  Sdiouwen  (1990).  Portions  of  the  discussion  in  this  section  are  t^en  from  Parnas  and 
Madey(1990).  The  four-variable  approach  extends  previous  work  on  embedded  system  requirements 
as  described  ^  Heninger  (1980)  and  Alspaugh  et  al.  (1992).  Many  of  the  notations  used  to  represent 
the  behavioral  model  are  derived  from  this  work.  The  four  variables  are  monitored,  controlled,  input, 
and  output  The  monitored  and  controlled  variables  are  collectively  called  the  environmental 
variables. 

23.1  EnvironmemtalVaiuables 

CoRE  views  a  software  system  as  existing  within  and  interacting  with  an  environment.  An  automotive 
engine  control  ^tem,  for  example,  odsts  within  an  environment  that  includes  the  engine  parts,  atmo¬ 
sphere,  external  load,  driver-controlled  devices,  and  so  on.  Only  certain  quantities  in  the  environment 
are  relevant  to  this  particular  system.  Pbr  example,  an  automotive  engine-control  system  needs  infor¬ 
mation  about  air  pressure  but  not  altitude.  An  aircraft-control  system  needs  information  about 
altitude;  air  pressure  is  a  means  to  measure  that  quantity. 

CoRE  represents  each  environmental  quantity  of  interest  with  a  mathematical  variable  (called  an 
environmental  variable)  so  that  there  is  a  clearly  defined  correspondence  between  the  variable  and 
the  environmental  quantity  it  models.  There  are  two  dasses  of  environmental  variables.  Monitored 
variables  represent  environmental  quantities  that  the  software  system  must  track,  e.g.,  the  ambient 
air  pressure.  Controlled  variables  represent  quantities  that  the  software  system  sets,  e.g.,  the  fuel  flow 
to  Ae  cylinders.  If  there  is  feedback  in  the  system,  a  variable  can  be  both  monitored  and  controlled. 
For  oounple,  the  automotive  engine  system  developer  might  define  a  monitored  variable  called 
/Ur^Pressure  measured  in  pounds  per  square  inch. 

233  The  CoRE  Relahons 

CoRE  captures  the  required,  externally  visible  software  behavior  as  a  set  of  relations  among  the  values 
of  monitored  and  controlled  variables.  A  CoRE  spedfication  maps  possible  values  of  the  monitored 
variables  to  acceptable  values  of  the  controlled  variables  (not  computer  inputs  to  computer  outputs). 
This  corresponds  to  an  intuitive  notion  of  required  behavior  in  that  it  relates  spedfic,  observable 
dianges  in  the  environment  (e.g.,  the  ambient  air  pressure  deaeases)  to  observable  actions  (e.g.,  the 
fuel  flow  is  deCTeased). 
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The  specification  of  required  behavior  in  response  to  undesired  events  (i.e.,  failures  of  system 
components  or  of  the  system  itself)  is  integrated  with  the  specification  of  “normal”  behavior.  &igi- 
neers  define  monitored  variables  to  denote  undesired  events.  This  allows  you  to  abstract  from  the 
sources  of  undesired  events,  such  as  spedfic  device  failures. 

The  behavioral  model  defines  the  required,  externally  visible  behavior  in  terms  of  two  relations  from 
monitored  variables  to  controlled  variables  called  NAT  (for  nature)  and  REQ  (for  required).  The 
NAT  relation  describes  those  constraints  placed  on  the  software  system  by  the  external  environment, 
e.g.,  physical  laws  and  the  properties  of  physical  ^tems.  These  are  [voperties  of  the  environment  that 
affect  the  software  but  exist  whether  the  software  exists  or  not.  For  software  requirements,  NAT  in¬ 
cludes  the  properties  of  the  monitored  or  controlled  hardware,  e.g.,  the  possible  states  of  physical  de¬ 
vices,  such  as  the  maximum  and  minimum  degree  of  a  flap’s  elevation.  The  REQ  relation  describes 
the  additional  constraints  on  the  controlled  variables  that  must  be  enforced  by  the  software.  In  writing 
REQ,  you  view  the  software  system  as  a  black  box  (Figure  2-1).  REQ  deso'ibes  properties  that  the 
software  system  (i.e.,  the  blade  box)  is  required  to  maintain  between  the  monitored  and  controlled 
variables. 


Core  treats  the  software  system’s  actual  inputs  and  outputs  as  resources  available  to  the  software  to 
determine  the  values  of  monitored  and  controlled  quantities.  You  complete  a  CoRE  spedfication  by 
describing  the  values  provided  by  the  system’s  hardware  devices  and  interfadng  software  systems  or, 
if  necessary,  suitable  abstractions  of  those  values  called  the  input  variables  and  output  variables 
(Figure  2-2).  The  relationship  between  the  software  system  input  and  output  and  the  environmental 
variables  is  oq^ressed  in  two  additional  relations  called  IN  (for  input)  and  OUT  (for  output). 


I^gure  2*2.  System  Viewed  With  Input  and  Output 
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A  CoRE  specification  is  made  precise,  testable,  and  analyzable  by  describing  the  required 
relationships  as  mathematical  relations.  A  relation  maps  the  elements  of  one  set  to  the  elements  of 
another.  Each  element  of  the  first  set  can  be  mapped  to  one  or  more  elements  of  the  second^.  The 
first  set  is  called  the  domain  of  the  relation;  the  second  set  is  called  the  range  of  the  relation.  In  Ck)RE, 
you  ^ically  represent  these  relations  by  mapping  the  possible  values  of  the  monitored  quantities  to 
the  acceptable  values  of  the  controlled  quantities.  This  provides  a  nonalgorithmic  desoiption  of  the 
required  behavior.  The  specification  is  complete  when  the  mailings  are  mathematically  complete; 
i.e.,  the  relation  defines  the  acceptable  values  of  the  controlled  variables  for  all  possible  values  of  the 
monitored  variables.  Sections  2.33  and  2.3.4  describe  the  CoRE  relations  and  their  mathematical 
model  in  more  detail. 

Figure  2-3  shows  the  sets  of  variables  and  relations  between  the  sets  of  variables;  constraints  within 
a  set  are  also  possible,  such  as  environmental  constraints  on  the  possible  values  of  individual  environ¬ 
mental  quantities.  The  NAT  relation  also  indudes  constraints  on  monitored  or  controlled  variables 
and  between  variables  of  the  same  type;  e.g.,  temperature  and  pressure  in  a  sealed  reaction  vessel  are 
related  quantities  and  change  together. 


REQ  and  NAT  Relations 
(ACC) 


Figure  2-3.  Tbe  Behavioral  Model  Relations 

The  relations  of  the  behavioral  model  allow  you  to  separate  concerns  for  what  the  software  system 
must  do,  viewed  as  a  black  box,  from  how  the  software  system  uses  available  hardware  resources  to 
do  its  job.  The  REQ  and  NAT  relations  desCTibe  requirements  that  will  change  if  the  purpose  of  the 
system  changes  but  will  not  change  if  a  hardware  device  is  modified  or  replaced  without  changing  the 
frmction  of  the  system.  The  IN  and  OUT  relations  change  if  assumptions  about  the  hardware  or  the 
hardware  itself  change  but  not  if  the  same  hardware  is  used  to  accomplish  a  slightly  different  purpose. 

CoRE  describes  behavioral  requirements  as  a  relation  from  monitored  quantities  to  controlled  quan¬ 
tities  rather  thaii  from  inputs  to  outputs  because  the  relationship  that  the  software  system  must  main¬ 
tain  between  the  monitored  and  controlled  quantities  is  usually  simpler,  easier  to  write,  and  more 
intuitive  than  the  relationship  between  inputs  and  outputs.  This  also  allows  the  analyst  to  focus  on 
the  behavioral  requirements  that  the  customers  and  users  are  concerned  with  independently  of  the 
hardware  issues.  For  example,  an  avionics  system  must  typically  track  and  report  the  aircraft’s  current 
position  to  a  certain  accurai^.  This  requirement  can  be  expressed  in  terms  of  monitored  and  con¬ 
trolled  quantities  by  stating  the  relationship  that  the  displayed  position  (controlled)  must  have 

2.  A  function  is  a  relation  in  which  each  element  ci  the  first  set  maps  to  exactly  one  element  of  the  second  set.  Tbe  CoRE 
relations  are  expressed  by  defining  the  ideal  behavior  as  a  function,  then  describing  the  allowed  deviation  from  ideal. 
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relative  to  the  actual  position  (monitored);  e.g.,  the  disjdayed  latitude  and  longitude  must  equal  the 
actual  latitude  and  longitude  plus  or  minus  one  tenth  of  a  degree.  The  actual  inputs  used  to  c^culate 
the  position  might  be  inaemental  accelerations  on  an  inertial  platform.  Spedfying  the  behavioral  re¬ 
quirements  in  terms  of  inaemental  accelerations  would  be  more  difficult  for  both  the  writer  and  the 
reader  and  does  nothing  to  imiivove  the  {X'edsion  of  the  spedfication. 

233  Relations  NAT  AND  REQ 

In  the  following  discussion,  monitored  quantities  are  denoted  as  mj;  m2,  ...,  ntp,  and  controlled 
quantities  are  denoted  as  C|,  ...,  <^.Because  certain  quantities  may  be  boA  monitored  and 

controlled  by  the  software  system,  these  lists  may  have  elements  in  common. 

Eadi  envircmmental  quantity  has  a  value  that  can  be  reomded  as  a  function  oi  time.  For  exanqile,  the  en¬ 
gine  tmnpn^ture  has  a  particular  value  at  some  given  time  lFcmt  a  given  envinmmoital  variable  V,  you 
write  the  fiinctkm,  giving  its  value  over  time  as  v'.  The  value  df  function  v' at  a  particular  time  r  is  writtm 
}^t).  It  also  makes  sense  to  talk  about  the  vector  of  all  monitmed  variable  functkms  or  all 

controlled  variable  functions  (c'i,<4 ...,  e^).  For  the  rntmitored  variables,  this  is  called  Ae  mtmitored  state 
function  and  is  written  Siinilarly,  the  amtrolled  state  fimction  is  written  0. 

233.1  Relation  NAT 

The  NAT  relation  desnibes  all  of  the  external  constraints  on  the  values  that  the  environmental 
variables  can  assume.  Physical  laws,  the  properties  of  {diysical  systems,  and,  where  software  is  con¬ 
cerned,  the  properties  of  the  interfacing  hardware  all  constrain  the  possible  values  that  the  monitored 
and  controlled  variables  can  assume  and  the  possible  relations  between  them.  For  example,  the  NAT 
relation  for  flight  program  software  might  spedfy  tiie  airaaft’s  maximum  rate  of  dimb,  maximum 
altitude,  and  other  constraints  typically  described  by  the  aircraft’s  fli^t  envelope. 

Relation  NAT  is  defined  as  follows: 

•  The  domain  of  NAT  is  the  set  of  vectors  containing  oractly  the  values  of  M*  allowed  by  the 
enviroiunental  constraints. 

•  The  range  of  NAT  is  the  set  of  vectors  containing  exactly  the  values  of  C'  allowed  by  the 
environmental  constraints. 

•  (M  0)  is  in  NAT  only  if  environmental  constraints  allow  the  controlled  variables  to  take  the 
values  described  by  0  when  the  monitored  variables  have  the  values  given  by  M*. 

NAT  is  a  relation  rather  than  a  function  because  there  are  typically  many  possible  values  of  the 
controlled  variables  for  a  given  set  of  values  of  the  monitored  variables. 

The  spedfication  of  NAT  is  important  because  it  explidtly  captures  the  limits  of  required  behavior. 
For  a  specification  to  be  complete,  it  needs  to  cover  the  set  of  possibilities  allowed  by  the  NAT  relation. 
In  particular,  it  must  define  all  the  possible  values  that  the  monitored  variables  can  assume,  all  the 
possible  values  that  the  controlled  variables  can  assume,  and  any  constraints  between  their  possible 
values.  Conversely,  you  need  not  spedfy  the  REQ  relation  for  any  state  not  included  in  the  NAT  rela¬ 
tion  because  it  cannot  occur.  Therefore,  the  NAT  relation  makes  explidt  the  environmental 
constraints  that  are  implidt  in  most  spedfications.  This  allows  a  well-defined  notion  of  completeness 
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o(»ttraints  that  «e  impUdt  in  iix)tt  spedflcatioos.  Tttib  alkm  a  wefl^l^iied  notfon  ctf  omiqiletaiess 
because  tiie  ana^  can  ensure  tibat  the  specification  describes  the  required  behaviOT  all  pos^e 
values  the  sttftware  will  encounter. 

RdatiMREQ 

The  software  system  imposes  additional  constraints  on  the  values  of  the  ocmtrt^ed  variaUes.  These 
constraints  are  what  you  typically  think  of  as  the  behavicval  requirements.  Fcx^  exanqde,  the  heater 
isrequiredtobeonif  dietenq)eratureinthe  reaction  vessel  fidls  below 500 d^ees.Equivalaidy,  the 
controlled  variaUe  that  is  the  heater  state  is  otmstrained  to  have  the  value  "(m**  vdienevar  the  state 
of  the  environment  is  such  that  the  monitored  variable  oorrespondiqg  to  the  vessel  t^nperature  has 
a  value  (tf  less  than  500  d^ees. 

Relation  REQ  is  defined  as  follows: 

•  The  domain  of  REQ  is  the  set  of  vectors  containing  die  values  of  ill'  allowed  by  die  environ¬ 
mental  constraints. 

•  The  range  of  REQ  is  the  set  of  vectors  containing  the  values  of  C'allowedby  the  environmental 
constraints. 

•  is  in  REQ  only  if  the  software  mi^  permit  the  controlled  variables  to  take  the  values 
described  by  C'  when  the  monitored  varit^les  have  the  values  given  by  Jif. 

REQ  is  Really  a  relation  rather  than  a  function  because  there  is  tolerance  in  the  required  behavior 
in  time,  value,  or  both.  This  means  that  eadi  monitored  variable  value  is  associated  with  more  than 
one  possible  value  of  the  controlled  variables.  For  examine,  an  aircraft’s  operational  flight  program 
is  eiqiected  to  show  the  current  altitude  {dus  or  minus  some  number  of  feet  This  is  another  way  of 
saying  that  for  a  given  externally  measurable  altitude,  there  are  a  number  of  acceptable  values  that 
the  program  can  disiday  and  stiU  satisfy  the  requirements  (i.e.,  any  of  those  within  the  range  of  the 
actual  altitude  fdus  or  minus  the  allow^  tolerance).  Where  disaete  outputs  permit  no  tolerance  in 
value,  there  is  fypically  tolerance  in  time  given  1^  the  maximum  delay  between  the  change  in  the 
monitored  value  and  the  conesponding  ouq)ut. 

While  REQ  is  a  relation,  the  requirements  often  will  be  easier  to  write  and  use  if  the  relation  is 
specified  giving  the  ideal  behavior  as  a  filiation,  then  specifying  the  allowed  tolerances  in  value  or 
time  separatefy.  This  follows  standard  engineering  practice  because  the  ideal  function  is  usualfy  mudi 
simider  than  the  comjdete  relation;  it  is  usually  easier  to  understand  the  ideal  behavior  first,  then  un¬ 
derstand  how  the  behavior  is  allowed  to  deviate  from  the  ideal.  The  approadb  also  provides  an  ap- 
profviate  separation  of  concerns  because  requirements  for  tolerances  can  diange  independently  of 
requirements  finr  ideal  behavior. 

23.4  Relahons  IN  and  OUT 

Ultimatefy,  the  system  development  process  must  identify  tiie  resources  available  to  the  software  to 
determine  the  values  of  the  monitored  variables  and  to  affect  the  values  of  controlled  variables.  Early 
in  the  process,  you  may  represent  these  resources  by  abstractions  of  the  ultimate  inputs  and  outputs. 
When  the  harchvare  b^mes  defined,  the  interface  devices  fvovide  these  values.  In  any  case,  a  com- 
(dete  specification  must  define  the  resources  available  to  the  software.  The  behavioral  model  cafmires 
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nKHiitored  variables  to  software  ^tem  inputs  (input  variables).  Relation  OUT  gives  the 
oonespcMKtence  from  sctftware  system  outjHits  (output  variables)  to  the  controlled  variables. 

Relation  IN  describes  what  the  software  will  see  in  terms  of  the  available  inputs  for  possible  values 
(rfthe  monitored  variaUes.  This  specifies  the  accuracywith  which  the  environmental  vriues  of  interest 
can  be  measured.  Let  P  denote  the  vector  (<*i.4  -•<«)  of  inputs  to  the  system. 

Relation  IN  is  defined  as  follows: 

•  The  domain  of  IN  is  the  set  of  vectors  containing  the  possible  values  of  M*. 

•  The  range  of  IN  is  the  set  vectors  containing  the  possible  values  of  P. 

•  (M^  79  ts  in  IN  only  if  P  describes  the  possible  values  of  the  inputs  when  describes  the 
monitored  values. 

Similarly^  relation  OUT  specifies  (mathematically)  how  the  controUed  variables  are  affected  1^ 
sending  particular  values  to  the  output  devices.  Let  &  denote  the  vector  (o\,  <4  4)  output 

of  the  system. 

Relation  OUT  is  defined  as  follows: 

•  The  domain  of  OUT  is  the  set  of  vectors  containing  the  possible  values  of  (P. 

•  The  range  of  OUT  is  the  set  of  vectors  containing  the  possible  values  of  O. 

•  {CP,  O)  is  in  OUT  only  if  O  desaibes  the  possible  values  of  the  controlled  variables  when  <P 
describes  the  output  values. 

In  the  FLMS  example  described  in  Section  3,  the  actual  device  used  to  determine  the  fuel  level  senses 
differential  pressure  and  represents  that  pressure  as  an  8-bit  unsigned  integer  with  a  particular  scale, 
offset,  and  time  delay.  For  this  case,  the  IN  relation  must  specify  the  exaa  relationship  from  the  actual 
fiiel  level  in  the  tank  to  the  values  that  the  program  receives  from  the  device.  Note  that  both  the  accura¬ 
cy  and  delay  assodated  with  the  device  are  necessary  parts  of  the  spedfication.  Like  REQ,  IN  and 
OUT  are  relations  because  input  and  output  devices  have  limited  accuracy.  Both  input  and  output 
devices  have  assodated  delays. 

By  induding  the  IN  and  OUT  relations  in  the  behavioral  model,  it  is  not  the  intention  of  CoRE  to  say 
that  a  given  software  requirements  dcxxunent  necessarily  describes  the  details  of  the  input  and  output 
devices.  It  is  understood  that  there  are  different  conventions  for  allocating  information  to  different 
types  of  documents  (e.g.,  requirements  versus  design).  The  exact  characteristics  of  the  hardware  may 
be  unknown  before  detailed  design.  Finally,  where  you  must  specify  a  system  as  layers  of  i^tract  ma¬ 
chines,  values  that  are  represented  as  monitored  and  controll^  variables  at  one  level  may  be 
represented  as  inputs  and  outputs  in  the  spedfication  of  the  layer  below. 

For  a  requirements  spedfication,  the  IN  and  OUT  relations  serve  two  roles.  First,  vihere  the  actual 
hardware  fxroviding  Ae  inputs  and  outputs  are  part  of  the  requirements  (i.e.,  their  use  is  not  at  the 
discretion  of  the  designer),  these  requirements  may  be  documented  the  input  and  output  variables 
and  the  IN  and  OUT  relations.  Second,  these  relations  are  useful  for  verifying  certain  properties  of 
the  requirements.  You  can  use  the  IN  and  OUT  relations  to  show  that  the  software  can,  in  practice. 
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die  requkan^t.  You  can  use  the  IN  and  OUT  relatkms  to  show  that  the  scrftware  can.  in  practice, 
monitor  die  quantities  it  is  supposed  to  track  and  control  the  quantities  it  is  siq)f)osed  to  affect  through 
die  amiable  inputs  and  outputs.  You  can  also  show  that  the  hardware  characteristics  are  adequate 
to  rapport  the  required  precision  of  the  monitored  and  ccmtrolled  quantities. 

« 

2A  THE  Core  CLASS  MODEL 

The  Core  dass  model  provides  a  set  of  facilities  for  packaging  the  behavioral  model  as  a  set  of 
object^  dasses,andstq)erdasses.  The  set  of  dasses  and  the  relationships  for  a  given  CoREspectfica- 
tkm  are  called  its  dass  structure.  The  dass  structure  is  constructed  using  the  facilities  {novided  by  the 
dass  model  The  dass  modd  provides  CoRE's  packaging  mechanisms. 

Core  dasses  provide  facilities  for  abstraction  and  enoqisulation.  We  define  abstraction  as  a  view  of 
a  proMem  that  extracts  the  essential  details  relevant  to  a  particular  purpose.  Encapsulation  is  the 
process  hiding  details  that  are  not  relevant  to  your  purpose  by  providi^  an  abstract  interface. 

Core  apfdies  these  basic  prindfries  to  requirements.  For  CoRE,  the  "purpose”  of  abstracting  and 
oicapsulatiqg  requirements  is  to  address  spedfic  padcaging  issues,  such  as  ease  of  diange,  ease  of  use, 
encapsulation  of  fiiz^  requirements,  and  reusability.  For  example,  if  you  eiqiect  that  certain  require¬ 
ments  assodated  with  controlling  an  airo’aft  engine  will  be  the  same  aooss  several  systems  (e.g.,  the 
same  engine  will  be  used  for  more  than  one  airoaft),  you  can  padcage  those  requirements  in  an  en¬ 
gine-control  dass.  The  dass  would  encapsulate  exactly  those  requirements  that  were  common  to  eadi 
use  of  the  engine.  The  resulting  class  would  then  be  reusable  across  the  systems  using  the  same  engine. 

Core  differs  from  most  object-oriented  apf^-oaches  in  its  separation  between  the  behavioral  model 
and  dass  model.  The  CoRE  dass  model  is  not  intended  to  express  requirements  or  constrain  subse¬ 
quent  design^.  For  this  reason,  CoRE  dasses  are  defined  entirely  in  terms  of  the  behavioral  model. 
Both  the  information  defined  on  the  interface  of  a  CoRE  dass  and  the  encapsulated  information  must 
be  part  of  the  definitions  of  the  behavioral  model  (e.g.,  part  of  the  definition  of  REQ,  NAT  IN,  or 
OUT).  The  definitions  and  relations  of  the  behavioral  model  are  packaged  as  a  set  of  dass  definitions. 
The  ^finitions  and  relations  of  the  behavioral  model  determine  the  software’s  required  behavior. 
The  dass  model  determines  how  that  information  is  structured,  which  definitions  are  shared  (can  be 
used  commonty),  and  which  definitions  cannot  be  shared. 

2.4.1  Objects  and  Classes 

The  packaging  mechanism  in  CoRE  is  the  dass,  a  template  for  an  object  A  dass  represents  a  piece 
of  the  requirements  specification  written  in  terms  of  die  behavioral  model.  The  requirements  allo¬ 
cated  to  a  dass  may  apfdy  in  the  same  way  to  several  components  of  the  software  apfdication  (e.g., ' 
a  dass  may  specify  the  requirements  assodated  with  controUing  eadi  of  the  engines  of  a  four-engine 
aircraft).  A  piece  of  a  requirements  specification  as  af^lied  to  a  spedfic  component  of  the  software 
ai^cation  is  an  object.  Thus,  the  requirements  for  controlling  the  left  inboard  engine,  for  controlling 
the  left  outboard  engine,  and  so  on  are  objects  corresponding  to  the  class  of  engine  control 
requirements. 


3.  Ifjmobject-orieDteddeagniiietbodiiised,tbeCoREdavstnicturepfovidesguidaiioeindetemiining^«^trequirenients 
have  oomnoa  properties  (e.g.,  are  likdy  to  change  together).  However,  the  designer  is  free  to  refine  or  alter  the  dass 
structnre  if  neoessaiy  sinoe  it  does  not  defrne  a  requirement  on  the  structure  of  the  design. 
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Rather  than  (Tcate  a  separate  piece  of  the  requirements  specification,  i.e.,  a  separate  object,  for  each 
jaece  of  the  software  application  to  which  the  requirements  may  be  apf^ed,  CoRE  groups  the  require¬ 
ments  that  aj^ly  identically  to  a  group  of  components  and  spet^es  them  in  terms  of  a  class.  The  basic 
distinctions  are  as  follows: 

•  OesK  A  class  is  a  template  for  an  object  or  a  set  of  related  objects.  A  class  defines  a  set  of 
requirements  or  terms  common  to  one  or  more  objects.  Adass  definition  has  an  interface  and 
a  set  of  encapsulated  information.  The  encapsulated  information  cannot  be  used  outside  of 
the  dass  definition.  Information  defined  on  the  interface  can  be  used  in  the  definition  of  other 
dasses. 

•  Ol^eet:  An  object  is  an  instance  of  a  dass  as  aj^lied  to  a  single  component  of  the  software 
application.  The  object  spedfies  a  subset  of  the  definition  of  REQ,  NAT,  IN,  and  OUT 
relations  (induding  definitions  of  the  variables  and  terms)  for  a  component. 

•  Jntafaeei  A  dass  interface  is  constrained  to  be  defined  using  only  terms.  A  term  must  be  an 
eaqjression  written  in  terms  of  the  monitc^-ed  variables;  e.g.,  monitored,  conditions,  events, 
and  jH’edicates  on  the  modes  are  all  terms.  Ibrms  provide  a  mechanism  for  abstracting  details 
of  the  behavioral  model. 

Because  the  requirements  assodated  with  each  object  of  a  class  are  the  same,  writing  out  the  object 
definitions  individually  would  introduce  redundant  information  wherever  there  is  more  than  one  ob¬ 
ject  in  a  dass.  Redundandes  in  the  requirements  uimecessarily  increase  the  size  of  the  spedfication 
and  make  it  harder  to  manage  changes,  lb  keep  the  spedfication  condse  and  to  avoid  redundancy, 
a  Core  spedfication  is  written  entirely  as  class  (not  object)  definitions  even  where  there  is  only  one 
potential  object  in  a  dass. 

EL4UPLB:  An  avioiucs  ^tem  monitors  (e.g.,  oil  pressure,  oil  temperature)  and  controls  (e.g., 
jaropeller  pitch)  each  of  the  engines  of  a  four-engine  aircraft.  The  requirements  implemented 
by  Ae  software  are  exactly  the  same  for  each  of  the  four  engines  (i.e.,  relations  spedfying  the 
required  behavior  are  the  same  «tcept  for  the  engine  number).  You  would  then  define  the 
engine  control  requirements  as  a  class.  Each  object  in  the  class  would  correspond  to  the 
requirements  for  one  of  the  engines.  The  spedfication  then  needs  to  contain  only  the 
definition  of  the  dass. 

2.42  Paceaging  Relationships  Among  Classes 

The  packaging  properties  of  a  CoRE  spedfication  are  determined  by  three  relationships  among 
CoRE  classes:  encapsulates,  depends-on,  and  generalization/spedalization.  The  spedfic  packaging 
(X'operties  of  your  spedfication  are  determined  primarily  by  these  relationships. 

2A2.1  Encapsulates 

A  CoRE  class  may  encapsulate  the  definition  of  other  CoRE  classes.  A  class  encapsulates  some  subset 
of  the  behavioral  spedfication.  One  benefit  of  encapsulation  is  that  it  limits  the  impact  of  change. 
Where  the  encapsulated  information  is  complex  or  parts  of  it  are  likely  to  change  independently,  addi¬ 
tional  packaging  may  be  useful.  Tb  address  such  issues,  CoRE  allows  you  to  define  a  class  in  terms  of 
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Other  dasses.  For  example,  a  dass  Valvejnterface  might  define  the  behavior  for  the  controlled 
variable  Valve  and  an  indicator  light  Valvejndicator  that  the  software  must  light  when  the  valve  is 
open.  These  are  packaged  as  part  of  the  same  class  because  their  values  change  together,  but  they  also 
represent  pieces  of  the  spedfication  that  can  change  independently;  e.g.,  the  hardware  used  for  each 
may  diange,  so  the  outputs  and  OUT  relations  may  change.  You  can  ensure  that  such  a  change  affects 
only  one  relation  by  defining  the  encapsulated  part  of  Valvejnterface  as  two  classes:  one 
encapsulating  the  requirements  for  Valve,  the  other  containing  the  requirements  for  Valve_lndicator. 

The  encapsulates  relation  induces  a  hierarchy  on  the  set  of  classes  called  the  encapsulation  strudure, 
i.e.,  dass  Valvejnterface  encapsulates  dasses  Valve  and  Valvejndicator  and  is  one  level  above  them 
in  the  encapsulation  hierarchy.  CoRE  constrains  the  encapsulates  relation  so  that  all  requirements 
are  defined  by  the  classes  at  the  leaves  of  the  hierarchy.  In  particular,  the  leaf  classes,  such  as  VeUve 
and  Valvejndicator,  must  contain  all  of  the  definitions  of  the  REQ,  NAT,  IN,  and  OUT  relations. 
Oasses  above  the  leaves  may  export  terms  defined  their  encapsulated  dasses  and  may  define  addi¬ 
tional  terms  that  are  functions  of  the  terms  or  variables  defined  by  their  encapsulated  classes. 
However,  they  may  not  define  other  parts  of  the  behavioral  variables  or  relations. 


2AJL2  Depends>on 

The  depends-on  relation  denotes  exactly  which  classes  use  what  information  provided  by  other 
classes.  Classes  may  use  each  other  only  by  using  the  terms  defined  on  the  class  interface.  A  class  X 
uses  a  term  T  provided  by  class  Y  only  if  X  employs  term  T  in  its  definition.  In  this  case,  we  say  that 
the  definition  of  class  X  depends  on  class  Y.  For  example,  in  Figure  24,  the  arrow  labeled  valve _open 


Legend 


Dependency 
Qass  Definition 


iMgure  2-4.  Graphic  Depiction  of  the  Depends-on  Relation 


denotes  that  the  term  valve_open  is  defined  on  the  interface  of  class  Valvejnterface  and  used  in  the 
definitions  of  classes  Tankjnterface  and  Operator Jnterface. 

Managing  the  depends-on  relation  is  critical  to  accomplishing  many  packaging  goals.  For  example, 
how  classes  depend  on  each  other  determines  which  requirements  changes  will  be  difficult  to  make 
and  which  will  be  relatively  easy.  If  many  classes  depend  on  information  that  changes,  then  all  those 
dass  definitions  may  need  to  change  as  well. 
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1A23  Gencralization/Specializatioa 

The  generalization/specialization  structure  is  used  to  denote  the  inheritance  relation.  Inheritance  is 
a  mechanism  for  spedfying  common  properties  among  a  set  of  classes.  A  superclass  defines  a  set  of 
common  properties  and  acts  as  a  template  for  a  dass,  much  as  the  classes  serve  as  templates  for 
objects.  You  may  define  one  or  more  subclasses  of  a  superdass.  Objects  of  a  subdass  inherit  the  prop¬ 
erties  of  the  superdass  plus  additional  properties  defined  by  the  subdass.  These  constructs  are 
defined  as  follows; 

•  Superclass:  A  superdass  in  CoRE  defines  a  set  of  requirements  or  terms  that  is  common  to  two 
or  more  CoRE  dasses.  A  superdass  is  defined  in  exactly  the  same  way  as  a  dass. 

•  bihaitanee:  Inheritance  denotes  the  requirements  or  terms  that  are  defined  by  a  superdass 
and  shared  among  its  subclasses.  In  CoRE,  a  dass  inherits  the  contents  of  its  superdass  by 
encapsulating  the  definition  of  the  superdass  and  using  the  superdass  interface  (i.e.,  the 
superdass  definition  acts  like  an  encapsulated  dass  for  each  of  its  subdasses). 

•  Subclass:  A  subdass  is  a  dass  that  is  defined  as  an  instance  of  a  superdass.  In  CoRE,  a  subdass 
spedalizes  the  definition  of  its  superclass  by  adding  or  constraining  requirements.  A  dass  may 
be  a  subclass  of  only  one  superdass. 

A  subclass  inherits  the  properties  of  a  superclass  by  using  the  terms  and  variables  defined  on  the 
superclass  interface.  A  subclass  of  a  superclass  is  constrained  to  use  all  the  information  defined  on 
the  interface  of  the  superclass  in  its  definition  but  may  add  or  constrain  information. 

You  use  Core’s  generalization/spedalization  structure  both  to  reduce  the  redundancy  in  a 
specification  and  to  make  commonality  in  requirements  ^lidt.  Where  there  are  two  or  more  classes 
with  many  requirements  in  common,  representing  these  requirements  in  a  superclass  reduces  the 
amount  of  spedfication  that  must  be  repeated.  In  addition,  the  use  of  a  superdass  makes  explidt  the 
commonality  between  the  subclasses,  giving  subsequent  developers  the  opportunity  to  simplify  the 
design. 


ExatFLEs  Fart  of  an  avionics  system  monitors  and  controls  the  aircraft’s  communications 
radios.  The  system  contains  two  types  of  data  entry  terminals:  one  Radio  Itme  Control  Panel 
(RTCP)  and  two  Command  and  Display  Units  (CDUs).  Both  imits  show  the  current  state  of 
each  of  the  aircraft’s  six  communication  radios.  The  crew  can  also  use  either  type  of  terminal 
to  select  a  given  radio  and  enter  a  new  frequency.  Firequendes  can  be  entered  numerically  by 
^ving  an  integer  from  1  to  28  corresponding  to  a  preset  frequency  or  by  entering  a  three-letter 
preset  nmemonic.  The  types  of  terminals  differ  in  that  only  the  CDUs  can  be  used  to  enter  a 
nmemonic  because  only  the  CDUs  have  letters  on  their  keypads.  Otherwise,  the  requirements 
for  getting  frequendes,  selecting  a  radio,  and  disj^aying  r^io  state  are  the  same  for  the  two 
types  of  termi^s. 

The  commonality  in  requirements  for  the  terminals  is  an  essential  part  of  the  problem  in  the 
sense  that  the  commonality  is  driven  by  common  imderlying  requirements  for  controlling  the 
radios  rather  than  being  an  inddental  artifact  of  similar  hardware.  You  can  make  such 
commonality  explidt  and  reduce  redundancy  in  the  spedfication  by  cheating  a  Radio  Ibrminal 
superclass  that  encapsulates  all  the  common  requirements.  You  would  then  define  a  CDU 
subdass  that  refines  the  Radio  Ibrminal  superclass  by  adding  the  requirements  assodated 
with  entering  frequendes  as  mnemonics. 
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Z4J  Allocating  THE  Behavioral  Model  TO  Classes 


The  class  definitions,  including  the  encapsulated  information  and  the  class  interface,  are  constrained 
the  behavioral  model.  In  particular,  all  of  the  interface  information  provided  by  the  classes  must 
be  OfH’essed  in  terms  of  the  environmental  variables.  Thus,  the  class  interfaces  only  provide 
information  in  terms  of  the  state  of  environmental  variables,  changes  in  their  state,  or  the  history  of 
such  changes.  This  keeps  the  model  consistent  with  CoRE’s  goal  of  providing  nonalgorithmic 
spedfication. 

A  representative  allocation  of  elements  of  the  behavioral  model  to  a  class  structure  is  shown  in  Hgure 
2*5.  While  an  actual  spedfication  will  be  much  more  complicated  in  terms  of  the  number  of  dasses, 
levels  in  the  class  hierarchies,  and  use  of  information,  the  complex  structure  is  composed  of  many  sudi 
simple  structures  that  are  used  repeatedly.  When  the  basic  structure  is  understock,  it  is  not  difficult 
to  read  a  CoRE  spedfication. 


Terms 


Gass  Interface: 

Gass  Interface: 

Gass  Interface: 

Monitored  Variable  Definition  Term  Definitions 

Term  Definitions 

None 

Encapsulated: 

Encapsulated: 

Encapsulated: 

Input  Variable  Definition 

IN  Relation  Definition 

Legend 

Gass  Definition 

^  •^^Dependenry 

Tbrm  Definitions 

Monitored  Variable 

^ - ►  Controlled  Variable 

Contrdled  X^iiable  Definition 
REQ  Function 

Tc^erance 

Allowed  Delay 

Output  \%riable  Definition 
OUT  Relation  Definition 

Figure  2-5.  (Canonical  Allocation  of  Beha>noral  Model  to  Gasses 

In  general,  a  class  that  defines  a  controlled  variable  defines  the  REQ  relation  for  the  variable.  The 
REQ  relation  is  defined  using  terms  defined  by  other  dasses  in  the  requirements  spedfication.  Other 
classes  can  define  finite  state  machines  (mcxle  mac^ne)  or  terms;  both  the  mcxles  and  terms  are  them¬ 
selves  required  to  be  functions  of  other  modes,  terms,  or  monitored  variables.  Thus,  the  internal 
classes  also  use  modes  and  terms  defined  by  other  classes.  Classes  that  define  monitored  variables 
provide  the  variable  or  terms  to  other  classes. 

The  CoRE  class  model  differs  from  others  in  that  class  interfaces  are  not  defined  in  terms  of 
operations  (also  called  methods,  access  programs,  or  functions)  and  object  interactions  are  not 
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defined  in  terms  of  messages.  Because  CoRE  is  intended  to  specify  only  required  behavior,  not  design. 
Core  uses  specification  techniques  based  on  the  behavioral  model  rather  than  i»rogranuning  (i.e., 
sets  and  relations  rather  than  operations  or  procedures).  You  spedfy  what  information  one  dass  may 
use  about  another  but  not  the  mechanism  by  which  it  will  be  used  (i.e.,  the  protocol  or  transfer 
mechanism). 
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3.  AN  EXAMPLE:  THE  FUEL  LEVEL  MONITORING 

SYSTEM 

Core  prindples  and  heuristics  are  illustrated  by  applying  them  to  a  small  real-time  ocample  called 
the  ELMS  Specification.  This  section  desoibes  the  FLMS  system  mission  and  requirements. 

The  FLMS  is  a  simplified  version  of  a  safety  shutdown  intern  that  is  part  of  a  shipboard  fuel  level 
monitoring  and  control  system.  The  overall  ^tem  provides  fuel  to  the  engines  and  moves  fuel  be¬ 
tween  the  shipboard  tanks  to  ensure  a  constant  supply  and  to  help  maintain  trim.  The  safety  shutdown 
system  is  a  separate  component  of  the  overall  system  that  shuts  down  the  fuel  pumps  under  unsafe 
conditions,  such  as  too  low  or  too  high  a  fuel  level  in  a  tank.  The  problem  is  simplified  by  allocating 
a  single  tank  and  pair  of  pumps  to  the  software  (a  similar  system  would  monitor  the  other  tank  or  en¬ 
gine  pairs).  The  example  also  assumes  a  relatively  simple  method  of  measuring  the  fuel  level  based 
on  differential  pressure  in  the  tank  (i.e.,  you  do  not  address  issues  like  extreme  roll  or  pitdi  f.iat  com¬ 
plicate  the  measure  of  fuel  level  in  a  real  shipboard  system).  The  FLMS  problem  is  based  on  a  similar 
problemby  Van  Shouwen  (1990).  Figure  3-1  showsafrontview  of  an  FLMS  pump  and  tank.  Theprose 
desCTiption  of  the  FLMS  problem  is  as  follows. 

The  design  of  a  fuel  control  system  typically  comprises  automatic  or  manual  control  medianisms 
(engine  and  fuel-level  control)  and  safety  monitoring  devices.  The  safety  monitoring  devices  include: 
foel  gauges  and  gauge  codes  that  convey  die  fuel  level  in  the  tank,  fusible  plugs  or  fuse  alarms  that  alert 
the  operator  when  the  fuel  level  is  too  low  or  too  high,  and  fuel  flow  rate  gauges  and  other  gauges  show¬ 
ing  the  engine’s  operating  conditions.  The  FLMS  is  intended  to  replace  or  complement  the 
above-mentioned  devices.  It  monitors  and  displays  the  fuel  level  in  the  tank  and  provides  visible  and 
audible  alarms  for  high  and  low  fuel  levels.  Vfith  the  currently  selected  hardware  configuration,  fuel 
level  is  displayed  in  a  window  on  a  cathode-ray  tube  (CRT)  display,  two  “annundation”  windows  on 
the  CRT  provide  visible  indication  of  es%eded  fiiel-level  limits,  and  the  computer’s  speaker  provides 
the  audible  alarm. 

In  addition  to  annundation  windows  and  the  alarm,  the  pumps  are  shut  down  under  the  following 
conditions:  (1)  when  the  fuel  level  is  too  high  because  an  overly  high  fuel  level  can  came  pipeline  rup¬ 
ture;  (2)  when  the  fuel  level  is  too  low  became  an  overly  low  fuel  level  may  result  in  the  engine  running 
dry  and  being  damaged;  and  (3)  when  the  monitoring  tystem  detects  that  it  is  tmable  to  determine  the 
fiiel  level  due  to  the  failure  of  a  sensor.  It  is  assumed  that  the  shutdown  mechanism  is  relay  operated. 
Hence,  the  FLMS  outputs  a  single  signal  when  the  pumps  are  to  be  shut  down. 

The  FLMS  provides  two  pmh  buttom  that  are  med  for  the  following  purposes:  (1)  the  button  labeled 
SELF  TEST  allows  the  operator  to  dieck  the  FLMS’s  output  hardware  while  the  system  is  shut  down; 
and  (2)  the  button  labeled  RESET  allows  the  tystem  to  be  brought  back  into  normal  operation 
following  a  shutdown  or  testing  as  long  as  the  fuel  level  is  within  a  specified  range. 
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Source:  Adapted  from  Shouwen  (1990) 

Figure  3-1.  Fuel  Level  Monitoring  System  Pump  and  Iknk  Configuration  (Front  View) 
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4.  REPRESEimNG  THE  Core  BEHAVIORAL 

MODEL 


This  section  describes  the  underlying  concepts  of  the  CoRE  behavioral  model  and  presents  the  syntax 
and  semantics  of  the  notation  used  to  represent  the  model.  It  also  defines  CoRE’s  approach  to  specify¬ 
ing  timing  and  accuracy  constraints.  Chapters  8  and  10  desoibe  how  and  when  the  concepts  and 
notations  are  applied  to  develop  a  CoRE  specification. 

The  behavioral  model  captures  the  software’s  required  behavior,  including  the  required  values  of  the 
controlled  variables,  the  timing  constraints,  the  modes  of  the  system,  and  the  conditions  and  events 
that  cause  modes  to  change.  As  discussed  in  Section  23,  the  CoRE  behavioral  mcxlel  captures  re¬ 
quired  behavior  in  terms  of  the  relationship  between  monitored  and  controlled  quantities  over  time. 
The  behavioral  model  captures  the  value  and  timing  requirements  using  two  complementary  views: 
(1)  the  functional  view  captures  the  software  behavioral  requirements  as  a  set  of  functions,  i.e.,  what 
values  the  software  must  produce;  and  (2)  the  dynamic  view  captures  required  timing  behavior  and 
sdieduling  characteristics,  i.e.,  when  the  software  must  initiate  and  complete  the  required  behavior. 

Core’s  functional  view  is  based  on  the  four-variable  model  (Pamas  and  Madey  1990).  lb  capture  the 
relations  of  the  four-variable  model,  CoRE  uses  the  following: 

•  Conditions  characterize  the  state  of  the  monitored  or  controlled  variables. 

•  Events  characterize  changes  in  the  state  of  environmental  variables. 

•  Mode  machines  (a  form  of  finite  state  machine)  characterize  the  history  of  events. 

•  Functions  define  the  required  values  of  controlled  variables  in  terms  of  conditions,  events, 
modes,  and  terms  (expressions  of  monitored  variables). 

•  Iblerances  define  the  range  of  acceptable  behaviors. 

The  relation  REQ  maps  every  possible  value  of  the  monitored  variables  to  acceptable  values  of  the 
controlled  variables,  lb  make  the  specification  of  REQ  readable,  CoRE  decomposes  the  relation  into 
parts.  In  particular,  there  is  a  set  of  functions  associated  with  each  controlled  variable: 

•  The  ideal  value  function  maps  each  value  of  the  rntmitored  variables  in  its  domain  to  an  ideal  value 
of  the  controlled  variable. 

•  The  tolerance  function  defines  the  acceptable  range  of  behaviors  for  every  possible  value  of 
the  monitored  variables. 


The  timing  constraints  define  the  acceptable  range  of  behavior  in  time  (e.g.,  acceptable  delay) 
for  all  possible  values  of  the  monitored  variables.  This  is  captured  as  part  of  the  dynamic  view. 
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Where  the  value  of  a  controlled  variable  depends  on  the  history  of  events,  the  controlled  variable 
function  is  written  in  terms  of  modes.  A  given  set  of  modes  may  be  used  to  define  many  controlled 
variable  functions.  Thus,  the  functions  and  modes  associated  with  one  controlled  variable  define  one 
part  of  the  REQ  relation  for  all  the  values  of  the  monitored  variables  that  determine  the  value  of  that 
controlled  variable.  The  union  of  all  of  the  controlled  variable  functions  and  modes  then  defines  the 
entire  REQ  relation.  For  convenience  in  the  following  sections,  the  part  of  the  REQ  relation 
associated  with  a  single  controlled  variable  is  described  as  the  REQ  relation  for  that  variable. 


The  Core  functional  view  is  illustrated  in  Figure  4-1.  The  arrows  show  v4tere  one  part  of  the 
representation  uses  another.  The  required  values  of  the  controlled  variables  are  written  as  a  set  of 
functions  in  terms  of  the  modes,  monitored  variables,  and  terms.  The  mode  machines  dtange  mode 
based  on  events  defined  as  changes  in  the  values  of  the  monitored  variables. 
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Figure  4-1.  Representation  of  CoRE’s  Functional  View 

As  for  REQ,  the  remaining  relations  of  the  four-variable  model,  NAT,  IN,  and  OUT  are  decomposed 
for  readabili^  and  specified  in  parts.  The  NAT  relation  is  decomposed  and  specified  along  with  the 
relevant  controlled  variable  functions  or  environmental  variables.  The  IN  and  OUT  relations  are  de¬ 
composed  so  that  the  part  of  the  IN  relation  associated  with  a  particular  monitored  variable  is  defined 
with  that  variable.  Similarly,  the  part  of  the  OUT  relation  for  a  controlled  variable  is  defined  with  that 
variable.  This  is  discussed  further  in  Section  11. 
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Core’s  dynamic  view  defines  the  required  behavior  in  time.  You  capture  the  dynamic  requirements 
by  sped^ng  the  scheduling  and  timing  behavior  relative  to  controlled  variables.  In  particular: 

•  Define  the  sdieduling  requirement  for  eadi  controlled  variable  function.  Specify  whether  the 
value  must  be  set  periodically  or  on  demand. 

•  Define  the  tolerance  in  time,  such  as  the  maximum  delay  allowed  to  set  or  update  a  controlled 
variable. 

Core  i^ovides  notations  for  re[vesenting  each  part,  both  the  fuiu^tional  and  dynamic  views.  The 
following  sections  introduce  the  notation  and  semantics  for  each  of  these  components  in  turn. 

4.1  REPRESENTING  THE  FUNCTIONAL  VIEW 

The  functional  view  specifies  the  required  behavior  of  the  controlled  variables  as  functions  of  the 
monitored  variables.  This  sectitm  describes  the  notation  and  semantics  of  each  of  the  elements  used 
to  represent  the  functional  view,  induding  monitored  and  controlled  variables,  conditions,  events,  and 
terms.  It  also  provides  a  set  of  tabular  representations  for  CoRE  functions:  condition  tables,  event 
tables,  and  selector  tables. 

4.1.1  MoNnoRED  AND  Co^^1tOIl£D  Variables 

Core  models  the  environmental  quantities  of  interest  with  monitored  and  controlled  variables.  The 
template  for  defilning  a  monitored  or  controlled  ^^riable  is  shown  in  Ihble  4-1. 


Ikble  4-1.  Ibrnplate  for  Monitored  and  Controlled  Variable  Definitions 


Name 

Type 

Values  Physical  Interpretation 

Variable  name 

VariaUe  type 

Possible  values  Description  of  the  quantity  modeled  by  the 

of  thevariaUe.  variaUe. 

•  Type.  Spedfication  of  the  units  of  measurement  for  the  variable  (e.g.,  feet,  pounds  per  square 
inch,  degrees).  For  enumerated  types,  use  ENUMERATED.  Fbr  Brolean  types,  use 
BOOLEAN.  You  may  also  define  types  as  needed. 

•  Vatua.  The  range  and  predsion  of  the  values  that  environmental  variables  can  assume  in 
value.  For  enumerated  variables,  list  the  values.  For  numeric  variables,  record  the  lowest  and 
highest  values  the  variable  can  assume.  The  predsion  can  be  given  as  a  dedmal  with  the  value 
(e.g.,  0.02)  or  separately.  This  spedfies  the  predsion  and  the  range  of  values  over  which  the 
software  is  required  to  be  able  to  track  a  monitored  variable  or  set  a  controlled  variable. 

•  Pl^ysical  Interpretation,  A  desaiption  of  the  relationship  between  the  monitored  or  controlled 
variable  and  the  quantity  that  the  variable  models.  The  physical  interpretation  relates  the 
quantities  used  to  write  the  spedfication  to  externally  visible  phenomena. 

4.1.2  CoNDmoNS 

In  CoRE,  the  information  that  characterizes  the  environmental  state  and  state  changes  is  recorded 
using  a  language  of  events  and  conditions.  A  condition  is  a  predicate  (i.e.,  a  statement  that  is  true  or 
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false)  about  the  values  of  environmental  variables  that  holds  for  a  continuous,  measurable  period  of 
time.  A  condition  characterizes  an  aspect  of  the  environmental  or  system  state.  For  examine,  if  alti¬ 
tude  is  a  monitored  variable,  mon_Attitude>500  feet  is  a  condition  that  is  true  or  false  for  an  aircraft 
at  any  given  time. 

A  condition  is  represented  by  a  Boolean  e:q>ression.  Compound  conditiorts  are  formed  by  coimecting 
two  or  more  conditions  using  the  logical  operators  AND,  OR,  and  NOT.  For  examine,  given  the 
conditions  C,  Ci,  and  C2,  the  following  are  compound  conditions; 

Compound  condition:  Is  trne  when: 

NOT  C  C  is  not  true 

C1ANDC2  Both  Cl  and  C2  are  true 

Cl  OR  C2  Cl  or  C2  or  both  arc  true 

The  operations  are  listed  in  the  descending  order  of  precedence.  You  can  use  parentheses  to  alter  the 
evaluation  order.  By  definition,  each  compound  condition  is  also  a  condition. 

4.13  EvEins  AND  Event  Expressions 

4.13.1  Definitions 

An  event  occurs  when  a  condition  changes  value.  Hence,  any  condition  has  two  kinds  of  events 
associated  with  it;  those  events  that  occur  precisely  when  the  condition  changes  from  false  to  true  and 
those  that  occur  when  the  condition  changes  from  true  to  false.  An  event  occurrence  is  a  moment  in 
time  when  a  condition’s  value  changes.  Each  event  occurrence  is  instantaneous  (takes  zero  time)  and 
atomic  (all  or  none  occurs). 

Event  expressions  are  used  to  represent  the  set  of  events  associated  with  a  particular  condition.  CoRE 
uses  the  notations  @T(C)  and  @F(C)  to  represent  event  expressions  denoting  changes  in  the  state 
of  a  condition  C.  An  event  denoted  @T(C)  occurs  at  any  moment  in  time  when  the  condition  C 
transitions  from  false  to  true  (Boolean  expression  evaluates  to  true).  Similarly,  @F(C)  signifies  any 
event  of  the  condition  C  becoming  false. 

For  example,  consider  the  monitored  variable  nion_Push_Button,  representing  the  state  of  a  push 
button.  At  any  moment  in  time,  the  button  is  in  one  of  the  two  possible  states:  pressed  or  released. 
The  following  event  expressions  denote  the  events  corresponding  to  changes  in  the  state  of  the  button: 

Event  expression:  Represents: 

@T(mon_Push_Button  =  pressed)  The  event  class  corresponding  to  a  change  in 

the  state  of  the  button  from  released  to  pressed 
@F(mon_Push_Button  =  pressed)  The  event  class  corresponding  to  a  change  in 

the  state  of  the  button  from  pressed  to  released 

Where  the  occurrence  of  an  event  depends  on  the  truth  or  falsehood  of  other  conditions,  CoRE 
provides  the  notation  @T(Ci)  WHEN  C2.This  event  occurs  at  any  instant  in  time  when  Ci  transitions 
from  false  to  true  while  (given  that)  C2  is  true  at  the  same  time. 

For  ^mple,  the  e^q^ression  @T(mon_Reset_Switch  =  pressed)  WHEN  term_Fuel_Level_Range 
=  withinlimits  represents  the  event  of  the  variable  mon_Reset_Switch  changing  value  to  pressed 
while  the  variable  temn_Fuel_Level_Range  has  the  value  withinlimits. 
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Compound  event  expressions  are  formed  by  connecting  two  or  more  event  expressions  with  the 
operator  OR.  Note  the  difference  between  ^(Ci  or  C2)  and  (§T(Ci)  or  @T(C2): 

•  The  event  @T(Ci  OR  C2)  occurs  vdien  the  disjunction  Ci  OR  C2  changes  value  from  false  to 
true.  This  occurs  v^en  one  coiKlition  becomes  true  at  a  time  when  both  were  false.  It  does  not 
occur  if  one  condition  becomes  true  vdiile  the  other  condition  is  already  true. 

•  The  event  @T(Ci)  OR  @T(C2)  occurs  ^en  either  event  occurs. 

4.13^  Implementation  Considerations 

The  above  definitions  of  conditions  and  event  exi»^essions  represent  an  ideal  view  in  the  sense  that 
the  definitions  abstract  from  the  practical  issues  involved  with  evaluating  conditions  and  detecting 
events  occurring  in  real-time.  For  example,  it  is  possible  for  two  or  more  occurrences  of  an  event  to 
happen  so  closely  together  in  time  that  the  software  cannot  distinguish  them  as  discrete  events. 
Similarly,  a  condition  may  be  true  for  such  a  short  interval  that  this  is  missed  by  the  software. 

Where  these  concerns  are  an  issue,  the  specification  must  describe  the  tolerances  in  behavior;  i.e.,  the 
minimum  interval  over  which  events  will  be  detected.  You  use  the  NAT  relation  to  record  {»'operties 
of  the  environment,  sudi  as  the  minimum  possible  interval  between  events.  CoRE  does  not  provide 
ai^  additional  notation  to  specify  the  tolerance  in  evaluating  conditions  or  event  expressions  so  any 
su^  spedfications  must  be  {vovided  in  the  commentary.  For  example,  you  should  specify  the  order 
of  evaluation  in  the  following  cases. 

1.  Consider  the  evaluation  of  @fT(Ci)  WHEN  C2  where  the  same  ortcrnal  stimulus  causes 
@F(C2)  to  occur  shortly  after  @T(Ci);  i.e.,  the  same  external  stimulus  causes  the  value  of 
condition  C2  to  change  from  true  to  false  shortly  after  @T(Ci)  takes  place.  In  this  case,  the 
implementation  must  use  the  value  of  C2,  obtained  most  recently  before  the  occurrence  of  the 
event  @T(Ci). 

2.  Consider  the  case  where  the  condition  C2  is  only  defined  (becomes  accessible)  after  the  event 
@T(Cx)  occurs.  In  this  case,  the  spedfication  must  dearly  state  that  C2  be  tested  only  after 
the  event  @T(Ci)  occurs. 

3.  Consider  the  case  of  two  ottemal  stimuli  Si  and  S2,  both  causing  the  event  @T(Ci)  to  occur 
so  that  S2changes  the  value  of  C2  from  true  to  false  or  from  false  to  true  v^le  Si  has  no  impact 
on  C2 .  If  both  stimuli  should  arrive  nearly  simultaneously  and  there  is  a  requirement  for  han¬ 
dling  Si  before  S2,  then  condition  C2  must  be  checked  both  before  and  after  evaluating 
@T(Ci). 

In  general,  the  spedfication  should  state  the  sequencing  and  timing  of  event  detection  and  spedfy  the 
order  in  whidi  the  conditions  in  an  event  expression  must  be  evaluated  if  the  correct  behavior  depends 
on  it 


4.1.4  Terms 

The  definition  of  several  controlled  variable  functions  may  depend  on  expressions  of  monitored 
variables.  Rewriting  the  same  expression  throughout  the  spedfication  can  be  tedious  and  error  prone, 
lb  simplify  the  spedfication  and  to  note  such  dependendes  explidtly,  CoRE  provides  terms  A  term 
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is  a  named  eq)ression  of  one  or  more  monitored  variables,  i.e.,  a  formula  that  defines  the  ooin|)utati(m 
oi  a  value  using  one  or  more  monitored  variables  to  which  you  have  asagned  a  name.  Eadi  term  has 
a  value  and  a  type  that  is  determined  by  the  type  of  its  constituent  monitored  variables  and  the 
tqierattns  ap{died. 

Using  terms,  you  can  abbreviate  or  replace  lengthy  oqx-essions  with  names.  The  notion  of  terms  in 
Col^  is  analogous  to  the  concept  of  language  macros  (textual  rei^acements)  in  some  ixogramming 
languages.  Here  are  the  most  common  reasons  for  defining  terms: 

•  'fo  shorten  a  comfdex  and  lengthy  event  o^ession  used  in  (me  or  mcwe  event  tables  or  a 
compound  condition  used  in  (me  or  more  condititm  tables.  The  use  oi  properly  defined  terms 
reduces  errors  of  inconsistentty  and  improves  the  cdarity  of  the  re]xesentations. 

•  Tb  abstract  a  complex  ezfwession  and  hide  its  details.  The  reason  may  be  that  you  have  not  yet 
finalized  the  deta^  or  you  might  want  to  (±ange  them  later. 

4.U  Capturing  State  History 

For  most  real-time  embedded  systems,  the  software’s  behavior  depends  not  only  on  the  current  values 
of  the  enviromnental  variables  but  on  how  those  values  have  changed  over  time  (i.e.,  the  history  of 
events).  For  example,  to  release  a  weapon,  the  pilot  must  select  the  weapon,  arm  the  weapon,  aim  the 
weapon,  pull  the  trigger,  in  sequence,  before  the  software  actually  releases  the  weapon.  In  CoRE,  the 
term  state  is  used  to  refer  to  the  set  of  values  of  the  environment^  variables  at  a  given  time.  The  state 
history  refers  to  how  those  values  have  changed  over  time.  Thus,  the  required  behavior  of  a  system 
is  usually  a  function  of  both  the  current  state  and  the  state  history.  CoRE  captures  such  environmental 
variable  state  history  using  a  form  of  finite  state  macdiine  called  a  mcxie  machine. 

The  following  discussion  assumes  that  the  reader  is  familiar  with  the  basic  concepts  of  finite  state 
automatons  and  their  representation  as  state  transition  diagrams  and  decision  tables. 

4.1,S.l  Modes  and  Mode  Machines 
A  mode  machine  definition  consists  of: 

•  A  finite  set  of  states  called  m<xles. 

•  A  distinguished  initial  mcxie. 

•  A  set  of  transition  events — events  that  cause  transitions  from  one  mode  to  another.  Mode 
transitions  are  atomic  and  instantaneous  (i.e.,  completed  in  zero  time). 

•  A  set  of  mode  transitions.  Eacdi  mcxie  transition  maps  a  mcxie  and  an  event  to  a  new  mcxie. 

A  mode  mac^ne  specializes  the  notion  of  a  state  macdiine,  first,  in  that  the  behavior  of  the  macdiine 
must  be  defined  entirely  in  terms  of  the  CoRE  behavioral  mcxlel  and,  second,  in  that  a  mcxie  machine 
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does  not  define  modes  the  mode  madune  are  defined  in  terms  of  the  states  (rfCoRE 

mivifoiuneiitsi  wisUes,  and  the  trsnsitioii  events  are  defined  in  terms  of  duinges  to  the 
eaviroimieiital  vsrisbles. 

You  define  a  mode  madiine  ming  a  form  of  state  tranation  diagram  called  a  mock  transition  diagram 
or  a  form  ai  state  transition  table  called  a  mode  transition  table. 

4.1^  Msde  IhuMition  Diagram 

A  mode  transition  diagrain  provides  a  gr  a|;diic  representation  of  a  mode  machine  fircmi  the  following 
oonoqponents: 

•  Modes  are  represented  by  rectangular  boxes  containing  the  names  of  the  modes  they 
refM’esent. 

•  Mode  transitkms  are  rqiresented  by  lines  with  arrovdieads  showing  die  direction  of  the  transition. 

•  'Dansition  events  are  represented  by  event  expressions  labeling  the  transition  arcs  where  the 
event  causes  a  transition. 

The  initial  mode  is  distinguished  by  a  mode  tran^ticm  terminating  in  tiie  initial  mode  with  no  source. 
Figure  4-2  shows  a  simple  mode  transition  diagram.  The  initial  mode  is  mcxie_ShLitdowri.  There  is  a  tran- 
sition  from  m(Xle_Shutdown  to  mode_Operatbig  on  occurrence  of  event_Resei  The  mode  madiine 
transitkxis  from  mocle_Ope(ating  to  mo^_Hazard  when  the  condition  l8rrrt_Ftiel_ljevel_Range  = 
wilhinimtts  becomes  fr^.  It  transitions  back  to  modejOperaUng  firom  mode_Hazard  if  the  event 
@T(termJHjeiJj9vel_Rarige  =  wftNnIfanKs)  WHEN  (NOT  term^Seiftsst)  occurs. 


I^g;ure4-2.  Examine  a  Mode  Iransitioa  Diagram 
4.13.3  Mode  Thmsition  Thbles 

A  mode  transition  table  provides  a  tabular  representation  of  a  mode  madiine.  Tkble  4-2  represents 
the  same  mode  machine  as  shown  in  the  mode  transition  diagram  in  Figure  4-2.  A  mode  transition 
table  has  the  following  form: 

4.  k  many  methods,  fSnite  state  macbmes  are  used  as  finite  controls  udiere  the  machine  peifomis^)ecific  actions  cn- executes 
functions;  the  form  of  finite  state  madiine  used  Rml-TIme  Structured  Analysis  as  descr&ed  in  Hatley  and  Pirbhai 
(1988).  In  CoRE,  the  machines  are  used  only  to  capture  state  infonnation.  That  state  infcamation  is  then  used  to  specify 
the  CoRE  relations. 
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•  The  cunent  mode  is  listed  on  the  left  side  under  the  column  heading  Current  Mode.  Every 
mode  of  the  machine  must  appear  once. 

•  The  set  of  possible  conditions  and  events  causing  a  mode  transition  is  listed,  one  per  column 
in  the  center  of  the  table. 

•  The  set  of  inodes  the  madiine  can  transition  to  from  each  cunent  mode  is  listed  on  the  right 
side  of  the  table  under  the  heading  New  Mode. 


Ikble  4*2.  Using  a  TkUe  to  Represent  the  Mode  Machine  In_Operation 


CumntMode 

^1 

1 

n 

1 

j. 

j' 

1 

^1 

New  Mode 

mode_Operatuig 

@F 

mode_Hazard 

mode_Hazard 

@T 

f 

mode_Operatmg 

@T 

t 

mode_Shutdown 

mode_Shutdown 

@T 

mode_Operating 

Eadi  row  in  the  taUe  specifies  an  event  that  will  trig^r  a  transititxi  finnn  the  cunent  mode  to  the  new  mode: 

•  A  table  entry  of  @T  under  a  condition  heading  C  denotes  @T(C)  and  implies  that  the 
triggering  event  occurs  when  the  condition  C  changes  from  false  to  true. 

•  An  entry  of  @F  denotes  @F(C)  and  implies  that  the  triggering  event  occurs  when  the 
condition  C  changes  from  true  to  false. 

•  The  lower-case  entries  t  and  f  correspond  to  the  WHEN  clause  and  signify  that  the  condition 
must  have  a  particular  value  when  the  event  occurs.  For  example,  an  entry  of  t  with  a  colunm 
heading  Y  means  WHEN(Y),  and  an  entry  of  f  means  WHEN(NOT  Y).  There  may  be  two 
or  more  t  or  f  entries  on  each  row;  in  this  case,  the  WHEN  dause  condition  is  the  conjunction 
of  the  corresponding  conditions.  If  a  condition  does  not  affea  a  particular  mode  transition, 
then  the  corresponding  box  is  blank. 

For  example,  there  is  a  transition  from  mode_Hazard  to  mocie_Operating  i^en  the  event 
(§T(Fuel_Level_Range  =  withinlimits)  WHEN  (NOT  tenn_Selflesl)  occurs  as  shown  by  the  @T  under 
the  condition  (Fuel_Level_Range  =  withinlimits  and  the  t  under  teim_Selftest  in  the  row  linking 
mocie_Hazard  and  mode_Operating. 
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4.U.4  Properties  of  Mode  MackiiMS 

A  mode  machine  must  be  defined  so  that  the  machine  is  in  only  one  mode  at  any  given  time.  This 
means  that  it  will  always  make  sense  to  talk  about  the  current  m^e  of  the  machine.  CoRE  jn^ovides 
standard  notation  for  referring  to  the  current  mode  of  a  machine  and  the  events  associated  witn 
entering  and  exiting  a  given  mode. 

For  each  mode  M  of  a  given  mode  machine  C,  there  are  two  related  events,  denoted  by  £NTERED(C, 
M)  and  EXrTED(C,  M),  occurring  exactly  vdien  the  mode  madiine  C  enters  and  exits  nKxie  M, 
respectively.  You  can  use  these  predefined  events  as  event  expressions. 

Core  also  provides  the  {^redefined  condition  INMODE(C,  M)  to  refer  to  the  current  mode.  The 
condition  INMODE(C,  M)  evaluates  to  true  if  mode  machine  C  is  currently  in  mode  M;  it  evaluates 
to  false,  otherwise.  Where  there  is  only  one  mode  machine  or  where  the  context  is  well  defined  (e.g. 
in  condition  or  event  tables),  the  parameters  of  INMODE  may  be  omitted.  Figure  4-3  illustrates  the 
relationship  between  the  predefined  events  ENTERED(C,  M)  and  EXITED(C,  M)  and  the 
predefined  condition  INMODE(C,  M)  for  a  given  madiine  C: 

Event:  Occurs  When:  Meaning: 

ENTER£D(M)  @T(INMODE(M))  Mode  M  is  entered 

EXITED(M)  @F(INMODE^))  Mode  M  is  exited 


Figure  4-3.  The  Semantics  of  INMODE,  EXTIED,  and  ENTEitED 

Any  number  of  mode  madiines  may  be  used  to  capture  distinct  aspects  of  the  software  behavior.  A 
CoRE  specification,  therefore,  may  include  a  set  of  concurrent  mode  machines.  Mode  transitions  in 
one  mode  machine  may  be  used  as  transition  events  in  another  mode  machine. 

4.1.6  Tabular  RsPRESEifrAnoN  of  Functions 

CoRE  provides  three  types  of  tables  for  recording  the  information  required  to  characterize  the 
controlled  variable  functions:  condition  tables,  event  tables,  and  selector  tables.  The  CoRE  tables  pro¬ 
vide  a  uniform,  standardized  organization  for  recording  information  and  for  promoting  conciseness 
and  comi^eteness  in  writing  specifications. 
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4.1^1  Condition  Tible 

A  oondition  table  is  used  to  represent  a  function  where  the  value  of  a  variable  is  a  function  of  the  modes 
and  a  set  mutually  exclusive  conditions.  For  examine,  use  a  condition  table  to  spedfy  the  value 
function  for  a  periodic  controlled  variable  (see  Section  4.2.1). 

Each  row  in  the  table  specifies  a  mode  or  a  group  of  modes  and  all  the  relevant  conditions  that  a£fe<x 
the  value  of  the  variable  v^le  in  the  mode.  Ihble  4-3  illustrates  the  general  format  of  a  condition  table. 
TheJSgiriession  in  the  bottom  row  specifies  the  value  of  the  variable  Kin  mode  given  that  the  condi¬ 
tion  CondHion  holds  true.  Thus,  to  determine  the  value  of  the  variable  for  a  given  mode  and  condition, 
(1)  locate  the  row  corresponding  to  the  mode,  (2)  within  the  row,  find  the  column  corresponding  to 
Ae  condition,  and  (3)  follow  the  column  to  the  bottom  of  the  table  to  find  the  value  of  the  controlled 
variable.  An  X  entry  in  the  body  of  a  condition  table  indicates  that  the  expression  at  the  bottom  of  the 
column  is  not  used  to  set  the  value  of  the  controlled  variable  in  the  mode  on  that  row. 

'IkUe4-3.  Format  of  a  Condition  Ihble 


Mode 

Condition 

Mode  3/7 

Condition^ 

•  • 

■  • 

*  • 

.  • 

ModeA^ 

Conditiortm^l 

• . 

C<mdition,^ 

Vkriable  K. 

Expressioni 

•  • 

Estpressioitn 

Each  condition  table  must  satisfy  the  following  aiteria: 

•  The  modes  of  a  condition  table  must  belong  to  the  same  mode  machine;  every  mode  in  the 
mode  machine  must  appear  only  once  in  the  table. 

•  The  conditions  in  each  row  must  be  mutually  exclusive. 

•  The  disjunction  of  the  conditions  on  each  row  must  be  true. 

•  The  expressions  specifying  the  value  of  the  controlled  variable  must  be  of  the  appropriate  type. 

Exahple:  The  periodic  controlled  variable  con_Altitude  (Ikble  4-4)  is  set  to  Value)  if  condition 
C)  is  true;  it  is  set  to  Value2  if  C2  is  true  \if4ienever  the  system  is  in  mode  Mi.  Whenever  the 
system  is  in  mode  M2  or  M3,  the  controlled  variable  is  always  set  to  Value).  In  mode  M4, 
con_Attitude  is  set  to  Value)  if  condition  C;  otherwise,  it  is  set  to  Value2.  Note  that,  in  mode 
Ml,  (C)  OR  C2)  must  be  always  true  and  (C)  AND  C2)  must  be  false.  This  is  the  case  because 
the  conditions  in  each  row  of  a  condition  table  must  be  mutually  exdusive  and  their  disjunction 
must  be  always  true. 

4.1.6,2  Event  Ihble 

An  event  table  is  used  to  rejxesent  a  function  where  the  value  of  the  variable  must  be  set  based  on 
the  occurrence  of  an  event.  For  example,  the  value  function  for  a  demand  controlled  variable  is  written 
as  an  event  table  (see  Section  4.2.2). 
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IkUe  4-4.  Example  of  a  Condition  IkUe 


Mode 

CondhkiBS 

Ml 

Cl 

C2 

Ml 

M3 

INMODE 

X 

M4 

C 

NOTC 

ooa_Altitiide  » 

Valuoi 

Valuci 

Eadi  row  in  the  table  specifies  a  mode  or  a  group  of  modes  and  all  the  events  that  cause  the  variable 
to  change  value  while  in  the  mode.  The  entries  in  the  body  of  the  table  are  event  expressions.  At  the 
bottom  of  the  table,  there  is  an  entry  corresponding  to  each  mode  and  event  combination,  defining 
the  value  of  the  variable.  An  X  entry  in  the  body  of  the  table  indicates  that  the  eziMression  at  the  bottom 
of  that  column  is  not  used  to  set  the  value  of  the  controlled  variable  in  that  mode.  The  table  is  arranged 
so  that  all  the  events  with  a  common  variable  expression  are  in  the  same  colunm. 

Ihble  4-5  illustrates  the  general  format  of  an  event  table.  The  Expression  in  the  bottom  row  q)edfies  vdiat 
the  value  of  the  variable  V  is  set  to  for  a  given  mode  ^  and  a  triggering  event  EventExprasionij.  Thus, 
to  determine  die  value  of  the  variable  for  a  given  mode  and  event,  (1)  locate  the  row  ccneqxmding  to 
the  mode,  (2)  within  the  row,  find  the  column  with  die  corresponding  event,  and  (3)  follow  the  column 
to  the  bottom  of  the  table  to  read  the  ejqiression  defining  the  variable  value. 

Ikble  4-5.  Fonnat  of  an  Event  Tkble 


Mode 

Event 

Modeil^ 

EventExpressioni^l 

•  « 

EverUExpnssioni^ 

•  • 

•  • 

• . 

•  • 

Modeil^ 

EventExpression,nl 

EventExpression,^ 

Variable  K. 

Exjpnssioni 

Ejqfression^ 

Each  event  table  must  satisfy  the  following  aiteria: 

•  The  modes  of  a  condition  table  must  belong  to  the  same  mode  machine;  every  mode  in  the 
mode  machine  must  appear  only  once  in  the  table. 

•  The  triggering  events  in  each  row  must  be  mutually  exclusive;  i.e.,  only  one  can  occur  at  a  time. 

•  The  expressions  specifying  the  value  of  the  variable  must  be  of  the  appropriate  fype. 

Exostle:  In  Ihble  4-6,  the  controlled  variable  con_Switch  is  set  to  closed  if,  while  in  mode 
Ml,  condition  C  changes  from  true  to  false.  con_SwKch  is  set  to  open  if  dianges  from  true 
to  false  while  in  M2;  it  is  set  to  closed  at  entry  to  M2  if  condition  Ci  is  true.  The  third  row  de¬ 
fines  a  groupng  of  modes  M3  and  M4.  In  this  case,  the  controlled  variable  con_Switch  is  set 
to  open  at  entry  to  either  of  the  two  modes;  however,  exiting  M3  and  immediately  entering  M4 
is  not  counted  as  a  new  event  occurrence;  hence,  con_Sv)ntch  is  not  set  to  open  again.  Similar¬ 
ly,  it  is  set  to  closed  when  leaving  either  M3  or  M4  but  not  entering  the  other  one.  The  con¬ 
trolled  variable  con_Switch  is  set  to  open  on  anting  Ms  and  is  set  to  closed  on  entering  Ms 


4-11 


4.  RepfCtenting  the  CoRE  Behavioral  Model 


if  Ca  is  true  at  the  entry  to  this  mode.  Notice  that  the  condition  @F(INMODE(M5))  is 
equivalent  to  EXITED  (M5). 

Table  4-6.  Example  of  an  Event  Ikbie 


Mode 

Events 

Ml 

X 

@F(q 

M2 

@F(Ci) 

@T(INMODE  AND  Ci) 

(M3.M4) 

ENTERED 

@F(INMODE) 

Ms 

@F(INMODE) 

ENTERED  ^dien  (C2) 

con_Switch  = 

open 

closed 

4.1.63  Selector  Ibble 

A  selector  table  is  a  tabular  representation  of  strictly  mode-dependent  information.  Each  row  of  the 
table  corresponds  to  the  modes  of  a  mode  machine  that  completely  determines  the  information.  The 
columns  provide  the  information  that  is  relevant  to  each  mode.  Eadi  column  heading  names  a  term 
or  controlled  variable  whose  value  is  specified  in  that  column.  Each  mode  of  the  mode  machine  must 
aiqjear  only  once  in  the  table.  Each  entry  in  the  body  of  the  table  must  depend  entirely  on  the  corre¬ 
sponding  mode.  An  X  entry  in  the  table  indicates  that  the  item  named  at  the  column  heading  is  not 
defined  in  that  mode.  Tkble  4-7  illustrates  the  general  format  of  a  selector  table. 

Use  a  selector  table  to  specify  a  term,  controlled  variable  function,  or  any  quantity  whose  definition 
is  completely  determined  by  an  active  mode. 

’niUe4-7.  Format  of  a  Selector  laUe 


Mode 

Name  or  Description  of 
Mode-Dependent  Entity 

•  • 

Name  or  Description  of 
Mode-Dependent  Entity 

Mode  Mi 

E)pre5sion2 

•  • 

Expnssionj 

•  • 

•  • 

ModeMn 

Expressioftn 

•  • 

Expressiortn 

Exahtle:  In  the  following  example  of  a  selector  table  (Ihble  4-8),  the  value  of  the  term 
term_Max_Level  is  50  in  mode_Operating  and  mode_Shutdown  and  12  in  mode_Failure. 


TaUe  4-8.  Example  of  a  Selector  Ibble 


Mode 

term_Max_Level 

mode_C)perating 

mode_Shutdown 

50 

mode_Failure 

12 

4.2  REPRESENTING  THE  DYNAMIC  VIEW 

The  ^amic  view  of  the  CoRE  behavioral  model  describes  the  timing  characteristics  and  scheduling 
requirements.  It  specifies  when  the  activities  described  in  the  functional  view  must  be  initiated  or 
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completed.  It  also  captu:es  the  scheduling  characteristics  (periodic  or  demand)  of  the  system’s 
required  behavior.  These  timing  requirements  are  defined  in  terms  of  the  externally  visible  behavior 
of  the  system.  For  example,  the  deadline  for  a  controlled  variable  function  is  defined  in  terms  of  the 
time  fi’om  the  occurrence  of  the  external  event  to  which  the  software  responds  by  setting  the  value  of 
the  controlled  variable. 

Scheduling  requirements  are  dassified  as  periodic  or  demand.  Where  a  controlled  variable  has  a 
periodic  scheduling  requirement,  its  value  must  be  set  at  regular  fixed  time  intervals;  i.e.,  the  initiating 
event  for  setting  its  value  is  the  passing  of  a  certain  amount  of  clock  time.  Where  a  controlled  variable 
has  a  demand  scheduling  requirement,  its  value  must  be  set  upon  the  occurrence  of  a  sporadic  event 
(e.g.,  button  pressed,  mode  changed,  etc.). 

4.2.1  Periodic  Scheduling 

A  controlled  variable  is  considered  periodic  if  it  must  be  set  or  updated  at  fixed,  regular  real-time 
intervals.  For  example,  a  value  that  must  be  supplied  as  part  of  a  feedback  control  loop  every  200 
milliseconds  has  a  periodic  scheduling  constraint 

lb  express  the  timing  characteristics  and  scheduling  requirements  of  controlled  variables,  you  must 
define  the  following  parameters: 

•  Period.  The  period  parameter  (P)  specifies  a  constant  time  interval  at  which  the  controlled 
variable  value  is  set  or  updated.  This  represents  the  time  between  two  consecutive  periodic 
cycles  for  setting  the  controlled  variable. 

•  Initiation  Delay.  The  initiation  delay  parameter  (I)  specifies  the  length  of  the  time  between  the 
start  of  any  periodic  cycle  and  the  earliest  time  the  system  is  allowed  to  update  the  controlled 
variable.  Only  after  tWs  period  is  elapsed  may  the  software  set  the  controlled  variable. 

This  is  an  optional  parameter  with  a  default  value  of  zero.  Where  the  initiation  delay  is  zero, 
the  controlled  variable  may  be  set  immediately. 

•  Completion  Deadline.  The  completion  deadline  parameter  (d)  specifies  the  time  by  which  the 
controlled  variable  must  be  set  or  updated  during  any  periodic  cycle. 

This  is  an  optional  parameter  with  a  default  deadline  at  the  end  of  the  period.  Where  the 
deadline  is  earlier,  you  must  specify  the  deadline  parameter. 

•  Initiation  and  Termination  Events.  Some  periodic  controlled  variables  are  set  only  under  certain 
conditions,  e.g.,  when  the  system  enters  or  is  in  a  particular  mode.  Use  the  initiation  and  termi¬ 
nation  parameters  to  specify  the  events  that  signal  when  the  controlled  variable  must  be  peri¬ 
odically  updated.  Where  the  initiation  and  termination  events  are  specified,  the  requirement 
is  that  the  controlled  variable  must  be  updated  periodically  at  fixed  time  intervals  during  the 
period  between  the  arrivals  of  the  initiating  and  terminating  events,  respectively.  For  a  con¬ 
trolled  variable  process  that  runs  continuously,  you  only  provide  the  initiating  event  (e.g., 
system  initialization). 

The  timing  characteristics  of  a  periodic  controlled  variable  may  vary  as  a  function  of  the  mode,  in 
which  case  its  scheduling  parameters  will  also  be  functions  of  the  mode.  Usually,  these  parameters 
are  constant  quantities. 


4-13 


4.  Rq>re»ciitiii3  the  CORE  Beh>vk)r«l  Model 


r 


Figure  4-4  depicts  the  relationship  between  the  periodic  scheduling  parameters.  Note  that  it  must  be 
the  case  that  d^P. 


i'‘‘ periodic 
cycle  starts 


I 

(initiation  delay) 


{‘^periodic 

cydeeods 


d 

(coin{detion  deadline) 


oontrdled  variable  is  set  during  this  inteival 
Hgure4-4.  Hme  Line  for  Periodic  CQntrcdIed\%iiabIenocess 

4.2.2  Demand  Scheduling 

A  controlled  variable  is  considered  demand  if  it  must  be  set  in  response  to  sporadic  events.  For 
example,  a  controlled  variable  that  must  be  set  vlien  a  button  is  pressed  or  a  mode  dtange  occurs  has 
a  demand  scheduling  constraint. 

lb  express  the  timing  characteristics  and  scheduling  requirements  of  demand  REQ  relations,  you 
specify  the  following  parameters  if  applicable: 

•  Initiation  Ddoy.  The  initiation  delay  parameter  (I)  spedfies  the  length  of  the  time  between  the 
detection  of  the  initiating  event  and  the  earliest  time  the  software  is  allowed  to  update  the  con¬ 
trolled  variable.  Only  after  this  period  is  elapsed  may  the  software  set  the  controlled  variable. 

This  is  an  optional  parameter  with  a  default  value  of  zero.  Where  the  initiation  delay  is  zero, 
the  controlled  variable  process  can  be  set  immediately  upon  detecting  the  initiating  event. 

•  Completion  Deadline.  The  completion  deadline  parameter  (d)  specifies  the  time,  measured 
from  the  occurrence  of  an  initiating  event,  which  the  controlled  variable  must  be  set.  It  rep¬ 
resents  the  maximum  acceptable  time  delay  between  the  detection  of  an  initiating  event  and 
generation  of  the  required  system  response  (i.e.,  the  worst-case  response  time). 

The  abilify  of  the  software  to  respond  to  initiating  events  depends  on  how  closely  together  such  events 
can  occur  in  time.  Where  events  can  occur  dosely  enough  for  this  to  be  an  issue,  the  NAT  relation 
should  spedfy  the  minimum  interval  between  events.  The  spedfication  of  the  controlled  variable  must 
discuss  the  acceptable  tolerance  in  behavior  (i.e.,  if  events  can  be  missed). 

Figure  4-5  depicts  the  relationship  among  the  demand  scheduling  parameters. 

Occasionally,  the  timing  characteristics  of  a  demand  controlled  variable  may  vary  as  a  function  of  the 
mode,  in  which  case  its  scheduling  parameters  will  also  be  functions  of  the  mode.  Usually,  the 
sdieduling  parameters  are  constant  quantities. 
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initMtingweiit 

drtected 


CoQtrolled  variable  is  set  m  this  time  interval 


Figured'S.  Time  Line  for  Demand  Controlled ‘NAriableRncess 

43  SPECIFYING  REQ,  NAT,  AND  UNDESIRED  EVENTS 

This  section  gives  an  overview  of  how  the  components  discussed  in  this  section  are  combined  to  spedfy 
the  behavior  of  a  controlled  variable. 

43.1  SpEciFnNG  Control!^  Variable  Behavior 


Ihble  4-9  shows  the  template  for  spedfying  a  controlled  variable  with  periodic  scheduling  constraints. 
Dible  4-10  shows  the  template  for  spedfying  a  controlled  variable  with  demand  scheduling  constraints. 

Ikble  4-9.  Ibmplate  for  a  Controlled  VariaUe  with  Periodic  Scheduling  Constraints 


Section  Title 

Brief  Description 

Controlled 

VariaUe 

Name  of  the  controlled  variaUe 

Initial  Value 

Expression  or  table  giving  the  initial  value  of  the  controlled  variable 

ModeQass 

Names  of  the  mode  classes  in  the  domain  of  the  controlled  variable 

Sustaining 

Conditions 

Conditions  that  must  hold  for  the  value  function  to  be  defined 

Value  Function 

Function  specifying  the  ideal  values  of  the  controlled  variaUe 

Iblerance 

Expression  or  table  giving  the  allowed  deviation  fiom  the  ideal  values  defined  by  the 
'vnlue  function 

NAT  Constraints 

Description  of  any  NAT  constraints  on  the  controlled  variaUe  behavior 

Period 

B!q>ression  giving  the  period  of  the  controlled  variable  function 

Initiation  Delay 

Ejqpression  grving  the  allowed  initiation  delay 

Completion 

Deadline 

E3q>ression  giving  the  allowed  deadline  (worst-case  response  time) 

Initiation  and 
Ibtmination 

Event  e]q)ressions  or  table  giving  the  initiating  and  terminating  events  for  the  periodic 
function 

Comments 

Additional  comments  or  descriptive  material 

For  each  controlled  variable,  you  must  define  a  complete  mapping  from  the  possible  states  of  the 
monitored  variables  to  the  possible  states  of  the  controlled  variable.  You  must  also  define  the  timing 
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and  scheduling  constraints.  The  templates  in  Ikbles  4-9  and  4-10  show  all  of  the  components  of  sudi 
a  specification  for  controlled  variables  with  periodic  and  demand  timing  constraints,  respectively. 

For  both  types  of  variables,  you  must  define  the  initial  value  and  identify  the  modes  for  whidi  the 
variable  is  a  function.  The  ideal  value  of  a  periodic  variable  is  defined  using  a  conditional  e}q>ression 
if  simple  enough  or  as  a  condition  table  if  the  variable  is  a  function  of  modes.  A  demand  variable  is 
defin^  using  an  event  expression  or  an  event  table  if  it  is  a  function  of  the  modes.  The  sustaining 
conditions  identify  any  conditions  that  must  be  true  for  the  function  to  be  evaluated;  i.e.,  it  identifies 
any  conditions  that  must  be  true  for  the  function  to  be  defined  and  the  conditions  to  be  evaluated. 

You  define  the  range  of  acceptable  values  by  defining  the  tolerance.  The  tolerance  is  specified  only 
for  numeric  values.  You  use  a  constant,  expression,  or  condition  table  to  define  the  acceptable  range 
of  values. 

lb  specify  any  relevant  parts  of  NAT,  you  use  the  same  components  used  to  specify  parts  of  the  REQ 
reflation.  The  remaining  parameters  are  used  to  specify  the  scheduling  constraints  and  tolerance  in 
time.  Here,  as  well,  you  may  use  condition  tables,  event  tables,  expressions,  and  so  on  to  describe  the 
required  behavior.  For  example,  if  the  initiating  and  terminating  events  of  a  periodic  variable  depend 
on  the  mode,  use  an  event  table  to  identify  the  events  that  initiate  or  terminate  the  periodic  behavior 
in  each  mode. 


Ikble  4-10.  Ibmplate  for  a  Controlled  Variable  With  Demand  Scheduling  Constraints 


Section  Title 

Brief  Description 

Controlled 

Variable 

Name  of  the  controlled  variable 

Initial  Value 

Esqiression  or  table  giving  the  initial  value  of  the  controlled  variable 

Mode  Class 

Names  of  the  mode  classes  in  the  domain  of  the  controlled  variable 

Sustaining 

Conditions 

Conditions  that  must  hold  for  the  value  function  to  be  defined 

Value  Function 

Function  specifying  the  ideal  values  of  the  controlled  variable;  typically  given  as  an 
event  table 

Tblerance 

E]q>ression  or  table  giving  the  allowed  deviation  from  the  ideal  values  defined  by  the 
value  function 

NAT  Constraints 

Description  of  any  NAT  constraints  on  the  controlled  variable  behavior 

Initiation  Delay 

Ejqpression  giving  the  allowed  initiation  delay 

Completion 

Deadline 

E]q>ression  giving  the  allowed  deadline  (worst-case  response  time) 

Comments 

Additional  comments  or  descriptive  material 

43.2  Specifying  NAT  Relations 

Use  the  NAT  relation  to  derive  the  types  and  ranges  of  the  monitored  variables  and  the  boimds  on 
the  REQ  relation.  The  NAT  relation  defines  all  the  values  that  the  monitored  and  controlled  variables 
can  assume  as  well  as  any  constraints  imposed  on  them  by  the  physical  world;  e.g.,  it  may  not  be 
possible  to  close  a  valve  (the  controlled  quantity)  at  certain  tank  pressures  (the  monitored  quantity). 
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As  you  identify  and  define  each  of  the  monitored  and  controlled  variables,  you  will  specify  its  fype, 
predsion,  minimum  and  maximum  values,  maximum  rate  of  change,  and  so  on  depending  on  how  the 
quantity  will  be  used.  These  values  are  typically  bounded  due  to  environmental  constraints  that  are 
totally  outside  the  control  of  the  software.  For  example,  if  the  system  must  monitor  an  aircraft’s  alti¬ 
tude,  the  airoraft’s  operational  ceiling  determines  its  maximum  value,  the  earth’s  surface  determines 
its  least  value,  and  so  on.  These  environmental  constraints  determine  the  useful  bounds  on  the  envi¬ 
ronmental  quantities;  the  software  may  require  less.  For  example,  there  are  altitudes  that  an  airCTaft 
will  never  reach. 

Use  the  NAT  relation  to  specify  the  bounding  assumptions  on  the  monitored  and  controlled  variables. 
You  then  use  this  information  to  define  the  ranges  over  which  the  software  must  monitor  the  quantities 
it  tracks  or  must  affect  those  it  controls.  Thus,  NAT  is  typically  used  to  derive  the  characteristics  of 
the  monitored  and  controlled  variables,  e.g.,  the  fype,  maximtun  and  minimum  values,  or  maximum 
rate  of  change. 

NAT  plays  a  similar  role  in  the  definition  of  the  REQ  relation  when  the  function  describing  REQ  must 
cover  all  the  possible  values  of  the  monitored  and  controlled  variables.  Use  the  NAT  relation  to  cap¬ 
ture  any  constraints  on  the  possible  relationships  between  a  controlled  variable  and  the  monitored 
variables  that  determine  its  values.  For  example,  when  the  possible  relationships  between  the  moni¬ 
tored  and  controlled  variables  are  constrained,  e.g.,  when  there  are  some  values  of  the  controlled  vari¬ 
able  that  cannot  occur  for  certain  monitored  values,  this  must  be  captured  in  the  NAT  relation.  This 
allows  the  reader  to  determine  that  the  REQ  relation  covers  all  the  possible  values  of  the  monitored 
and  controlled  quantities  (i.e.,  it  is  complete). 

You  use  the  same  basic  components,  i.e.,  mathematical  expressions,  conditions,  events,  condition 
tables  and  so  on,  to  specify  NAT  as  you  do  to  spedfy  REQ.  You  may  also  use  illustrations  or  even  prose 
if  the  constraints  cannot  be  captured  more  rigorously. 

43  J  Specifying  Required  Responses  to  Undesired  Events 

Over  its  operational  life  ,  any  real-time  embedded  system  will  experience  undesired  events,  the  failure 
of  components  of  the  sy.  t  .;m  or  of  the  system  itself.  Sensors  fail  to  provide  inputs  or  are  used  in  operat¬ 
ing  conditions  that  affect  the  accuracy  of  the  inputs  they  provide.  Software  databases  become  cor¬ 
rupted,  leading  them  to  provide  inconsistent  data.  Actuators  fail  to  respond  to  commands  or  their 
performance  degrades.  The  communication  lines  connecting  devices  fail.  These  failures  may  be 
temporary  or  permanent. 

When  specifying  a  system,  engineers  must  consider  and  account  for  undesired  events  that  the  system 
is  likely  to  encounter.  The  requirements  specification  must  describe  the  required  behavior  of  the 
software  when  it  encounters  these  undesired  events. 

Core  treats  the  response  to  undesired  events  just  as  it  treats  other  requirements;  i.e.,  the  software’s 
response  to  undesired  events  must  be  specified  the  REQ.  However,  you  will  occasionally  create 
ad^tional  monitored  variables  spedfically  to  denote  failure  conditions;  in  particular,  you  may  create 
them  to  model  the  inabilify  of  the  software  to  get  the  value  of  a  monitored  variable  or  set  a  controlled 
one. 

These  additional  monitored  variables  are  used  in  the  REQ  relation  to  specify  required  system 
behavior  on  the  occurrence  of  undesired  events,  e.g.,  to  trigger  mode  changes  or  determine  the  value 
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of  a  controlled  variable.  These  monitored  variables  abstract  from  the  system  components,  i.e.,  th^ 
do  not  unnecessarily  assume  or  preclude  particular  system  components  or  a  particular  system  design. 
They  are  defined  in  terms  of  the  inability  of  the  system  to  measure  a  monitored  variable  or  measure 
it  to  the  desired  predsion  or  in  terms  of  the  inability  of  the  system  to  affect  the  controlled  variable  or 
to  affect  it  to  the  desired  tolerance. 
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This  section  describes  the  underlying  concepts,  ^taz,  and  semantics  for  representing  the  CoRE  dass 
model.  The  dass  model  [vovides  the  set  of  facflities  fen  packaging  the  behavioral  model  as  a  set  (rf 
dasses  and  dependendes.  You  nail  use  the  concepts  and  notations  described  in  this  section  to  develop 
and  document  a  dass  structure  for  your  software  requiremorts.  Adass  structure  represents  the  set 
of  dasses  and  relationships  for  a  given  CoRE  specification.  The  process,  guidelines,  and  heuristics  for 
api^lying  the  dass  notation  to  padoge  the  be^vimral  requirements  are  described  in  Sectitm  9. 

The  goal  in  creating  a  dass  structure  is  to  padca^  the  behavioral  modd  to  fadlitate  ease  (tf  diange, 
CTeate  reusable  requirements,  and  develop  parts  of  the  software  in  parallel,  lb  achieve  these  goals, 
you  use  the  concepts  of  abstraction  and  encapsulation  in  decomposing  the  requirements  into  a  dass 
structure.  You  decompose  the  behavioral  m^el  into  a  set  of  dasses,  eadi  of  u^ch  may  be  refined 
independently.  The  process  of  decomposing  requirements  allows  you  to  analyze  and  understand  large, 
complex  systems.  ^Mth  CoRE,  decomposition  is  based  not  on  al^rithmic  decomposition  (e.g.,  steps 
taken  to  [vocess  an  input)  but  rather  (xi  the  behavioral  model  (e.g.,  monitored  and  controlled 
quantities,  software  modes,  and  terms). 

The  class  model  contains  dasses  with  well-defined  interfoces  and  dependendes  on  these  interfaces. 
The  dass  model  provides  the  medianisms  to: 

•  Manage  requirements  changes  (via  abstraction,  encapsulation,  and  inheritance). 

•  Create  reusable  requirements  (via  abstraction,  encapsulation,  and  inheritance). 

•  Develop  parts  of  the  software  system  in  parallel  (via  classes  and  their  dependendes). 

The  CoRE  class  model  provides  the  medianisms  to  padtage  the  behavioral  model  as  a  set  of  dasses, 
objects,  and  dependendes.  The  sections  that  follow  tell  you : 

•  The  mechanism  for  gaining  a  preliminary  understanding  of  the  software  and  its  environment 
(recorded  in  an  information  model) 

•  What  information  to  record  about  eadi  dass  (dass  definitions,  interfaces,  encapsulated 
information) 

•  The  diagramiitg  notatioa  for  showing  a  dass  structure  (omtext  diagram  and  dqioidency  ffzpbs) 

•  The  information  and  diagraming  notation  for  each  component  of  a  dass  definition 

5.1  INFORMATION  MODEL 

The  Core  information  model  serves  a  different  purpose  than  a  traditional  data  model  (e.g.,  those 
used  to  spedfy  complex  data  requirements  as  outlined  by  Chen  [1976])  in  that  you  use  the  iiiformation 
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model  to  idoitify,  collect,  andorgRnize  the  infc^mation  you  will  need  for  subsequent  CoRE  activities.  You 
use  an  informatim  model  to  obtain  a  preliminaiy  understanding  of  the  software’s  envirrmment.  Ihis  in¬ 
dudes  «itities  whose  behavior  can  affea  the  software  behavior,  t^aracteristics  (rf  these  entities  (physical 
quantities  diat  the  sc^tware  monitors  and  controls),  and  the  relatitmships  among  instances  these 
entities. 

You  can  use  the  information  model  in  building  both  the  CoRE  behavioral  model  and  dass  model. 
First,  the  physical  quantities  that  you  identify  help  in  determining  the  environmental  variables  and 
the  assodations  that  must  be  maintained  by  the  FIEQ  or  NAT  relation  in  the  behavicn-al  model.  Se¬ 
cond,  identifying  entities  and  capturing  sin^arities  among  entities  aid  in  identifying  dasses  and  the 
inheritance  relation  in  the  dass  model. 

An  entity  is  a  representatkm  of  any  aq)ect  the  ^stem  envirmunent  that  is  of  interest  to  foe  systent 
Entities  in  the  information  modd  describe  physical  things,  rdes  {dayed  by  persons  organizations,  ind- 
dmits,  and  interactkms  that  are  significant  to  the  software.  Fc»'  eadi  entity,  you  rectvd  foe  information 
found  in  IhUe  5-1. 


lhUeS-1.  Entity 'Ibiiq>late 


SectkmTItk 

Brief  Description 

Entify  Name 

The  name  of  the  entify 

Entify  Description 

Brief  prose  descrqition  of  what  the  entify  represents 

Attributes 

List  of  attributes  that  characterize  the  entity 

Instances 

List  of  number  of  instances  that  you  have  identified 

An  attribute  characterizes  some  important  aspect  or  fact  about  an  entify.  Consider  physical  quantities  that 
nu^  be  relevant  to  the  software.  The  software  may  monitcn^  or  control  these  quantities,  or  fodr  values  may 
mfiuence  quantities  that  foe  software  rocmitCHS  or  ccmtrols.  Provide  a  defifotion  for  each  attribute  that 
describes  the  assodatitm  between  the  {foysical  quantify  and  the  attribute  that  derates  it  figure  5-1  shows 
an  examine  of  foe  entify  Pump  and  its  attributes  from  the  FLMS. 

Pump 

•  SfautdownReb^ 

*  Jcwg _ 

FiguieS-1.  Punq>  Entity  and  Attributes  Example 

You  impede  organization  on  foe  entities  by  creating  relationships  between  entities.  The  relationships 
you  CTcate  are  foe  generalization/spedal^tion  (see  Section  5.1.1),  aggregation  (see  Section  5.1.2), 
and  application-spedfic  (see  Section  5.1.3)  relationships. 

There  are  a  variety  of  notations  you  can  use  to  represent  a  CoRE  information  model,  e.g.,  an 
entify-reladonship  diagram  (ERD)  (see  Figure  5-2),  a  text-based  list  of  candidate  environmental 
variables,  or  an  attribute  matrix  (see  Thble  5-2). 

•  ERD:  Use  the  ERD  to  create  a  graphic  representation  of  entities  and  relations.  The  ERD  uses 
rectangles  for  entities  and  diamonds  for  relationships  with  lines  connecting  related  entities. 
Attributes  of  entities  are  shown  as  text  within  the  entify  symbols. 
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Figure  5*2.  Eati^BrietkinAip  Dkgrem  Nbutioo 

•  Attribute  Matrix:  You  can  represent  relations  between  entities  using  a  table  that  maps 
attributes  to  attributes.  Place  the  attribute  names  in  the  first  column  and  first  row.  Haoe  an 
X  in  the  intersection  for  pairs  of  attributes  in  the  value  of  one  determines,  {vescribes, 
or  constrains  the  value  of  the  other. 

IkUe  5-2.  Ihrtial  Attribute  Matrix  for  Fbel  Level  Monitoring  System 


5.1.1  GBNERAUZimOI^PECIALlZAllONRSlAnONSlIIP 

The  generalization/spedalization  relation  recognizes  that  an  entity  may  be  related  to  a  set  of  entities 
by  being  a  generalization  of  the  entities  in  the  set.  Attributes  that  diaracterize  the  more  general  entity 
also  characterize  the  members  of  the  set.  The  members  of  the  set  may  specialize  the  general  entity 
by  adding  or  constraining  attributes  and  may  inherit  its  attributes. 

Use  the  generalization/specialization  relation  to  record  which  entities  inherit  similar  characteristics. 
Recording  this  information  will  help  you  in  subsequent  class  structuring  activities  to  identify  common 
requirements  and  help  you  understand  which  ch^es  are  likely  to  occur  together. 

Rei»’esent  the  generalization/spedalization  relationship  with  an  is_a  relationship  in  an  ERD.  Capture 
those  attributes  that  are  common  among  a  set  of  entities  with  the  is_a  relationship  and  assodate  those 
attributes  with  the  generalization  entity.  An  endfy  can  have,  at  most,  one  generalization  parent  entify. 
For  example,  consider  an  air  traffic  control  system  that  tracks  potential  target  aircraft  in  which  host 
and  target  airCTaft  are  spedalizations  of  the  aircraft  entify  (see  Figure  5-3).  The  attribute  Location 
applies  to  both  the  Host  andlhrget  Airaaft  entities;  therefore,  it  is  assodated  with  the  Aircraft  entity 
(generalization  entify).  However,  the  speed  of  the  target  aircraft  (attribute  Relative  Speed)  relative 
to  the  host  aircraft  oi^^  applies  to  the  Ikrget  Aircraft  entify  attribute;  therefore,  it  is  assodated  with 
the  Ikrget  Airaaft  entify  only. 

5.1.2  Aggregation 

The  aggregation  relation  imiicates  that  one  or  more  entities  are  part  of  another  entify.  This 
relationship  allows  you  to  rejM-esent  entities  as  components  of  an  entire  assembly. 

Use  the  aggregation  relationship  to  help  in  understanding  the  software’s  environment  and  also  to 
provide  structure  to  the  information  model.  There  may  be  information  or  relationships  that  the 
software  must  maintain  that  belong  to  the  aggregate  but  not  to  any  of  the  parts  individually. 
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Figure  S-3.  Oenerelgatkip/^pecMlmticin  Eatity-RdetiooAy  Dugram  NoUtko 

Bepresrat  the  aggregation  relationship  with  an  is j[)art_of  relation.  Fbr  ezamjde,  an  operator  console 
that  contains  an  alarm  and  dis[day  may  need  to  ensure  that,  when  an  alarm  is  sounding,  the  disf^ay 
must  reflect  the  condition  that  the  alarm  is  signaling  (see  Figure  5-4). 


Rgure5-4.  Aggregation  Enti^Relatioiidiip  Diagram  NbUtioa 

5.13  AppLiCM3K>N-SpEcinc  Relationship 

An  application-specific  relationship  represents  a  logical  association  between  entities.  A  logical 
association  can  be  a  physical  or  conceptual  connection  between  entities.  For  example,  a  target  aircraft 
flies  relative  to  a  host  aircraft.  **Flies  relative  to”  is  the  logical  association  between  the  two  entities. 

You  use  application-specific  relationships  to  capture  an  early  understanding  of  what  information  you 
will  need  to  write  the  REQ  and  NAT  relations.  The  attributes  of  one  entity  may  be  needed  to  set  the 
attributes  of  another  entity.  These  entities  may  be  connected  via  a  logical  assodation. 

You  name  the  application-specific  relationship  using  the  terminology  consistent  with  the  software 
application.  You  can  re*'  mt  the  apj^cation-^pedfic  relationships  using  an  ERD  (see  F^nre  5-5) 
or  an  attribute  matrix  Ihble  5-2).  These  a^ociations  should  be  named  with  a  verb  ^^i^mse. 

53  CLASS  DEFINITIONS 

The  CoRE  dass  model  provides  a  set  of  facilities  for  padtaging  the  behavioral  model  into  a  structure 
consisting  of  classes  and  their  dependencies  ami  the  inheritance  relation.  Adass  serves  as  a  temi^ate 
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for  an  object  or  a  set  of  related  (Ejects.  A  class  defines  a  set  of  requirements  or  terms  common  to  one 
or  more  objects  and  {vovides  facilities  for  abstraction  and  encap^ation.  An  object  is  an  instance  of 
a  class  that  specifies  a  subset  of  the  definition  of  REQ,  NAi;  IN,  and  OUT  relations  for  a  given  spedfi- 
cafion.  A  CoRE  specification  is  written  in  terms  of  dasses  (not  objects)  to  keep  the  specification 
concise  ai^  to  avoid  redundancy. 

'fo  define  a  dass,  you  need  to  identify  its  name,  description,  dass  interface,  encapsulated  information, 
the  name  and  number  of  objects  defined  each  dass,  and  traceability  information  (see  Ihble  5-3). 
The  definition  partiti<xis  the  information  into  what  can  be  used  by  other  dasses  (the  dass  interface) 
and  what  cannot  be  used  by  other  dasses  (encapsulated  information).  How  you  represent  each  of 
these  diaracteristics  is  discussed  in  later  sections. 

lb  complete  a  dass  structure,  you  must  also  define  and  represent  the  relationships  among  dasses. 
These  relationships  are  the  encapsulates  relation,  depends-on  relation,  and  the  inheritance  relation. 
Section  2.4  show^  that: 

•  The  encapsulates  relation  allows  you  fo  define  a  dass  in  terms  of  other  dasses. 

•  Hie  depends-on  relation  denotes  exactfy  u^bicb  dasses  use  information  provided  by  other  dasses. 

•  The  inheritance  relation  denotes  a  dass  containing  common  properties  to  be  shared  among 
a  set  of  classes. 

The  sections  that  follow  show  you  how  to  represent  a  class  structure  graphically,  induding  the  set  of 
classes  and  the  relationships  among  them. 


TkUeS-3.  Qass  Ibmplate 


Scctkm  Title 

Brief  Description 

Class  Name 

Use  a  descriptive  name  (e.g.,  one  recognizable  by  the  customer)  to  communicate  the 
dass  abstraction  preoed^  with  *dass_”  or  ‘*si^rdass_”  (e.g.,  class_Alann). 

Qass  Description 

Brief  prose  description  of  vriiat  the  dass  encapsulates  and  the  abstraction  it  provides. 

Qass  Interface 

Information  that  can  be  used  by  other  dasses  in  their  definitions. 

1.  I^unes  and  definitions  of  mmiitored  or  contidled  variaUes  that  the  dass  defines. 
Begin  the  monitoied  vaiiaUe  name  with  ‘hion_’’  (e.g^  mon_Fbel_Level). 

2.  b^mes  and  ddEinitions  of  terms  that  the  dass  defines.  Use  a  descr^tive  name 
preceded  with  ’‘iermj’  (e.g.,  termJ[nside_Hys_RangB). 

3.  Rovide  names  and  definitions  ofary  events  that  the  dass  defines.  Use  a  descriptive 
name  preceded  with  "event  ”  (e.g.,  event  Reset). 

4.  Provide  names  and  definitions  of  any  noodes  that  the  dass  defines.  Use  a  descrqjtive 
name  preceded  with  "irxxlej’  (e.g.,  mode_ppeiatitig). 

the  Core  Oast  Model 


Ikbte  5-3,  continiwd 


SectfenTitic 

Brief  Descriptioo 

Ea£ap8olated 

Isfmnation 

Infonnatk>n  that  cannot  be  used  by  ai^  other  dass: 

1.  Names  and  definitions  of  monitored  variables. 

2.  Names  and  definitions  of  controlled  variables. 

3.  Names  and  definitions  of  events. 

4.  Names  and  definitions  of  terms. 

5.  Names  and  definitions  of  input  and  output  vatiaUes. 

6.  Definitions  of  REQ  relations. 

7.  Definitions  of  NAT  relations. 

8.  Definitions  of  IN  relations. 

9.  Definitions  of  OUT  relations. 

— or— 

10.  Names  and  definitions  of  dasses  and  their  dependendes  if  not  a  leaf  dass. 

Objects  Defined 

List  the  name  of  each  object  derived  fiom  this  dass  (e.g.,  Engine  1,  Engine  2,  Engine 

3,  and  Engiiie  4  would  be  objects  derived  from  dass_Engiae).  Objects  are  derived  only 
fiom  das^  at  the  leaves  of  the  hierarchy,  so  this  se^on  can  be  empty  if  the  dass  is  a 
higher  level  dass. 

Subdasses 

Defined 

If  this  template  describes  a  superclass,  list  the  subdasses  derived  fiom  the  superdass 
here. 

Itaoeability 

Specify  whidi  requirements  are  defined  the  dass.  This  section  is  filled  only  for  leaf 
dasses. 

S3  DIAGRAMING  CONVENTIONS 

Figure  5-6  illustrates  the  diagraming  notation  you  use  to  show  a  class  structure.  The  following  sections 
desaibe  how  the  graphic  elements  are  used  to  illustrate  the  relationship  between  the  software  and  its 
environment  and  the  dependent^  relationships  among  classes. 


53.1  Context  Dugram 

The  Core  context  diagram  illustrates  the  boundaries  between  the  software  and  the  external 
environment.  Specifically,  the  CoRE  context  diagram  shows  the  monitored  and  controlled  variables 
in  and  out  of  the  software  system  unlike  the  information  model,  whidi  implies  no  directional 
information.  The  diagram  identifies  the  entities  and  the  environmental  quantities  needed  by  the 
software. 
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Entity 


nion_Vbriable_Name 


oon_\briable_Nanie 


The  context  diagram  (see  Figure  5-7)  contains  a  drcle  that  represents  the  CoRE  specification  as  a 
^<diole.  You  further  decompose  the  software  system  class.  Each  rectangle  represents  an  entity  from  the 
information  model.  An  anow  connecting  a  rectangle  to  the  circle  represents  an  environmental 
variable.  Label  the  arrow  with  the  name  of  the  environmental  variable  that  it  represents  (e.g., 
mon_Variable_Name,  con_Vai1abie_Na(Tie). 


mon  ^brMbIe  Name 


con  Vuiable  Name 


Figure  S-7.  Representatioa  of  an  Overview  c£  a  Spedfication  Using  a  ConteiU  Diagram 

Arrows  representing  monitored  variables  can  originate  only  from  an  entity  on  the  context  diagram. 
Likewise,  the  arrows  for  controlled  variables  can  terminate  only  at  an  entity  on  the  context  diagram. 
An  arrow  horn  a  rectangle  to  the  drcle  represents  a  monitored  variable,  and  an  arrow  from  the  drcle 
to  the  rectangle  represents  a  controlled  variable.  Tb  reduce  the  number  of  arrows  contained  in  a 
context  diagram,  you  can  aggregate  monitored  variables  originating  from  the  same  entity  into  a  single 
arrow.  Similarly,  you  can  aggregate  controlled  variables. 

SJ.2  Dependency  Graph 

The  depends-on  relation  denotes  which  classes  use  what  information  provided  by  other  class 
interfaces.  Formally,  the  depends-on  relation  is  defined  as: 

class_X  uses  T,  where  T  can  be  a  monitored  variable,  term,  mode,  or  event,  provided  by  dass_Y 
only  if  class_X  employs  T  in  its  definition. 

You  show  these  relationships  in  a  dependent^  graph.  An  arrow  between  two  dasses  represents  an 
interface  provided  by  the  dass  at  the  tail  of  the  arrow,  which  is  needed  to  define  the  class  at  the  head 
of  the  arrow.  Label  each  arrow  with  the  name  of  the  environmental  variable,  event,  or  term  that  it 
represent"  (see  Figure  5-8). 

In  establishing  the  dependendes,  it  is  important  to  remember  that  a  dependency  shows  only  that  the 
defim'tion  of  a  term  defined  by  one  dass  is  used  by  another.  It  implies  nothing  about  how  the  data  may 
appear  in  an  implementation  or  how  it  actually  moves  from  one  place  to  another.  In  particular,  it  does 
not  imply  that  there  is  some  form  of  “request”  for  the  data  followed  by  some  form  of  “send.”  CoRE 
dasses  are  not  operational  and  do  not  perform  actions  like  requesting  and  sending. 
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Figure  S-8.  Dependency  Graph  NoUtion 


5  J  J  Leveling 

You  re|X'esent  the  encapsulates  and  depends-on  relations  as  a  set  of  leveled  diagrams.  The  root  of  the 
hierar^y  is  the  CoRE  context  diagram.  Leveling  allows  you  to  decompose  a  dass  into  more  detailed 
dasses  (encapsulates  structure),  providing  a  means  to  manage  complexity  in  the  detailed  require¬ 
ments.  You  could  represent  the  leaves  of  the  hierarchy  as  a  single  diagram;  however,  your  ability  to 
understand  the  spedfication  decreases  due  to  the  amount  of  information  shown.  The  higher  level 
diagrams  are  abstractions  of  the  lower  level  diagrams  (see  Figure  S-9). 


Figure  5-9.  Class  Structuring  Leveling  Diagrams 
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You  also  show  the  dependencies  among  classes  at  each  level  of  the  encapsulation  structure. 
Notationally,  this  means  that  dependencies  into  and  out  of  a  class  on  a  parent  diagram  must  be  equiva¬ 
lent  to  the  dependencies  into  and  out  of  a  child  diagram.  This  is  referred  to  as  balandng.  In  other 
words,  all  dependencies  into  a  child  diagram  must  be  drawn  coming  into  the  parent  class.  Similarly, 
all  dependencies  out  of  a  child  diagram  must  be  drawn  going  out  of  the  parent  class  (see  Figure  S-9). 

The  leveled  set  of  diagrams  represents  the  decomposition  of  the  software  system  class  on  the  context 
diagram.  All  arrows  representing  the  monitored  variables  come  into  the  Level  0  diagram.  Similarly, 
all  arrows  representing  the  controlled  variables  exit  the  Level  0  diagram  (see  Figure  5-9). 

5.4  CLASS  SPECIFICATION 

Ihble  5-3  defined  the  components  of  an  individual  class.  This  section  expands  on  the  definition  of  each 
component  as  well  as  shows  you  how  to  graphically  represent  them.  The  definition  partitions  the  infor¬ 
mation  into  what  can  be  used  by  other  classes  (the  class  interface)  and  what  cannot  be  used  by  other 
classes  (encapsulated  information).  The  inheritance  relation  is  also  discussed. 

5.4.1  Class  Interface 

A  class  interface  defines  information  (e.g.,  monitored  variables  or  expressions  of  monitored 
variables)  that  can  be  used  in  the  definition  of  other  classes.  A  class  interface  is  an  abstraction  in  the 
sense  that  it  hides  extraneous  details  and  shows  only  essential  aspects  of  the  information  defined  by 
the  class.  Equivalently,  there  is  a  one-to-many  relationship  between  the  interface  and  the  possible  in¬ 
ternal  structures.  For  a  CoRE  class,  the  abstract  interface  comprises  the  information  defined  by  the 
class  that  other  classes  can  use. 

In  developing  the  class  interface,  you  must  seek  a  balance  between  sometimes  conflicting  goals: 
providing  a  useful  interface,  preserving  the  encapsulated  information  of  the  class,  and  maintaining 
ease  of  use: 

•  Provide  a  us^ul  interface.  Your  first  objeaive  is  to  provide  sufficient  information  about  each 
monitored  variable  so  that  you  can  fully  specify  the  REQ  relations  that  depend  on  those 
variables. 

•  Preserve  the  etKapsidated  irrformation.  The  class  encapsulated  information  characterizes 
information  that  other  classes  should  not  depend  on.  You  must  define  an  interface  that  does 
not  provide  information  that  is  part  of  the  class  encapsulated  information. 

•  Maintain  ease  of  use.  In  developing  the  class  interface,  you  create  information  to  be  used  in 
other  parts  of  the  requirements.  Your  objective  is  to  define  the  interface  terms  so  their 
meaning  is  clear,  precise,  as  simple  as  possible,  and  unambiguous. 

The  actual  information  provided  on  a  given  interface  depends  on  the  information  defined  in  the  class, 
what  information  is  needed  by  the  classes  defining  the  REQ  relations,  and  the  packaging  goals.  How¬ 
ever,  CoRE  restricts  the  interface  specification  to  contain  only  monitored  variables,  modes,  terms, 
and  events  (expressions  of  the  monitored  variables). 

To  illustrate  a  class  interface,  label  an  arrow  from  the  class  wnth  the  name  of  the  environmental 
variable  or  term  that  is  defined  by  the  interface.  For  example,  consider  Figure  5-10:  mon_A  is  on  the 


5.  Rgpfocntjng  »l»e  CoRE  Oass  Model 


interfiux  of  class_B,  mon_D  and  term_C  are  on  the  interface  of  class_G,  and  ciass_H  has  no 
interface.  The  controlled  variables  and  the  REQ  relations  are  defined  in  the  encapsulated 
information  for  the  classes  (see  Section  5.4.2). 


Figure  5-10.  OeasIoteiiueNoUtioo 

The  arrows  between  classes  represent  depends-on  relations.  The  dass  at  the  head  of  the  arrow  uses 
the  definition  that  appears  on  the  interface  of  the  class  at  the  tail  of  the  arrow.  Arrows  representing 
monitored  variables  originating  from  an  entity  on  the  context  diagram  are  defined  by  the  dass  at  the 
head  of  the  arrow.  Arrows  representing  controlled  variables  terminating  at  an  entity  on  the  context 
diagram  are  defined  by  the  class  at  the  tail  of  the  anow.  In  Figure  5-10,  class_B  defines  mon_A  and 
con_B,  dass_Q  defines  mon_D,  and  class_H  defines  con_F. 

5.4.2  Class  ENCAPSuiAiiei)  iNTORMATioN 

The  encapsulated  information  for  a  class  is  information  that  caimot  be  used  by  other  classes.  The 
encapsulated  information  for  a  given  class  must  either  decompose  into  a  more  detailed  dass  structure 
or  provide  definitions  of  part  of  the  behavioral  model.  Thus,  the  encapsulation  structure  is  a  hierarchy 
of  classes  and  subclasses,  the  leaves  of  which  containonly  definitions  of  environmental  variables,  input 
and  output  variables,  and  REQ,  NAT  IN,  and  OUT  relations.  Because  traceability  information  is  tied 
to  the  behavioral  model  (e.g.,  environmental  variables,  REQ,  NAT,  IN,  OUT),  you  trace  requirements 
only  in  the  leaf  dasses. 

When  a  class  becomes  too  complex  (i.e.,  its  definition  becomes  unmanageable)  or  parts  are  likely  to 
change  independently,  additional  packagii^  may  be  useful.  You  provide  this  packaging  by  defining  a 
class  in  terms  of  other  dasses,  i.e.,  by  encapsulating  the  defim'tion  of  a  class  in  a  parent  class.  This  rela¬ 
tionship  induces  a  hierarchy  on  the  set  of  classes  by  using  leveling.  This  is  constrained  so  that  all  re¬ 
quirements  are  defined  by  the  classes  at  the  leaves  of  the  hierarchy  (e.g.,  the  encapsulated  information 
would  be  written  in  terms  of  monitored  variables,  controlled  variables,  REQ,  NAT  IN,  or  OUT). 
Classes  above  the  leaves  may  export  terms  defined  tty  their  encapsulated  classes,  and  they  may  define 
additional  terms  that  are  functions  of  the  terms  or  variables  defined  by  their  encapsulated  dasses. 

Figure  5-11  illustrates  the  notation  for  the  encapsulated  information.  The  class  class_B  encapsulates 
the  definition  of  class_l  and  class_J  in  its  encapsulated  information.  The  interface  of  class_l  defines 
t6rm_X  in  its  interface,  and  class_J  encapsulates  the  definition  of  the  controlled  variable  con_B  and 
the  REQ  relation  for  con_B.  The  classes  ciass_  I  and  class_J  are  the  leaves  of  the  hierarchy  for 
class_B.  'Ifaceability  information  would  be  found  in  classj  (assodated  with  IN  relation  for  the 
monjA)  and  ciass_J  (assodated  with  REQ  relation  for  con_B). 

5.4J  Objects 

An  object  is  an  instance  of  a  class  that  spedfies  a  subset  of  the  definition  of  REQ,  NAT,  IN,  and  OUT 
relations,  induding  the  definitions  of  ^e  variables  and  terms,  for  a  given  spedfication.  There  is  no 
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Level  n+i 
claas_B 
decomposed 
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graphical  icon  for  a  CoRE  object;  however,  you  do  need  to  identify,  by  name,  the  objects  spedfied  by 
eadi  class  if  these  objects  will  be  referred  to  individually.  If  you  need  to  specify  more  than  one  object 
of  a  Core  class,  use  the  following  conventions: 

•  Names  of  monitored  and  controlled  variables  and  terms  should  be  sufGxed  by  a  pair  of  angle 
brackets  ( <  >)  containing  the  identifier  of  the  object  or  a  variable  ranging  over  the  possible 
identifiers;  e.g.,  a  variable  called  <location>  could  denote  a  range  of  objects  for  pilot  and 
copUot. 

•  Function  definitions  for  classes  whose  objects  use  terms  or  monitored  variables  firom  multiple 
objects  of  other  classes  may  need  to  be  written  in  terms  of  specific  objects. 

Consider  a  control  system  for  a  four-engine  aircraft  whose  CoRE  specification  contains  the  definition 
of  class_Engine  with  a  monitored  variable  mon_Englne_Temperature  and  a  term_Engine_Fall.  The 
dass  definition  would  contain  the  names  of  the  four  objects: 

Number  of  Objects  Spedfied:  4 
Object  Names: 

left_out  (left  outboard  engine) 
leftjn  (left  inboard  engine) 
right Jn  (right  inboard  engine) 
right_out  (right  outboard  engine) 

The  definition  of  the  monitored  variable  mon_Englrje_Temperature  and  the  term  term_Engine_Fail 
would  be  the  same  for  all  four  objects.  Graphically,  class_Engine  would  be  depicted  by  Figure  5-12. 


mon_Engine_Temperature, 


tenn_Engine_RuI 


class_En^ne] 


Figure  5-12.  class_£ngine  Diagram 
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However,  suppose  that  there  is  a  mode  machine  class  definition  modeciassJn_Emergency,  whose 
single  object  monitors  all  four  engines  and  initiates  emergency  actions  as  appropriate.  If  a  special 
action  needs  to  be  taken  when  both  left  engines  fail,  the  associated  condition  is  defined  as: 

tenn_Engin©_Fail<left_out>=True  and  term_Engine__Fail<leftJn>=True 

Graphically,  the  mode  machine  dass  and  assodated  terms  can  be  represented  as  shown  in  Figure  5-13. 


Figure  5>13.  dass_Engii»  Diagram  With  Objects 


5.4.4  Inheritance 

The  generalization/spedalization  structure  is  used  to  denote  the  inheritance  relation.  Inheritance  is 
a  mechanism  for  spedfying  in  a  superclass  the  common  requirements  and  properties  that  are  shared 
among  a  set  of  subclasses.  A  superclass  defines  a  set  of  common  properties  or  requirements  for  sub- 
dasses.  Each  subclass  of  the  superclass  inherits  the  requirements  or  terms  defined  by  the  superclass. 
The  subclass  inherits  the  interface  of  its  superclass  by  encapsulating  the  definition  of  the  superdass 
(i.e.,  the  superdass  definition  acts  like  an  encapsulated  class). 

When  defining  functions  of  a  subclass  where  you  need  to  indude  terms  or  monitored  variables  from 
the  superclass,  separate  the  class  names  with  a  period  (e.g.,  mon_Var_Name.subclass_Name, 
term_Name.subclass_Name), 

Examples  You  have  defined  the  following  superclass  (Ihbie  54)  and  subclasses  (Ihbles  5-5  and 
5-6).  Graphically,  represent  the  superclass  as  encapsulated  information  of  a  subclass.  Figure  5-14 
illustrates  both  the  naming  convention  and  the  graphical  representation  for  superclass_A 
class_B,  and  class_C  (in  Figure  5-14,  class_D  and  class_E  represent  classes  encapsulated  by 
class_B  and  class_C,  repedively).  The  variable  mon_A.class_B  represents  the  class_B 
monitored  variable  mon_A  (defined  by  superclass_A). 
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Class  Name 

superclass_A 

Qass  Description 

Superclass  capturing  the  common  requirements  for . . . 

Class  Interface 

Defines; 

mon_A :  definition 

Encapsulated 

Infonnation 

Encapsulates: 

con_B :  definition 

Subclasses  Derived 

class_B  and  class_C 

lYacealnliQ' 

This  dass  encapsulates  the  following  requirements  . . . 

5.BfWManflicOoKEC>ilindri 


IkUeS-S.  dass_B  Ifanidate 


QassName 

dassJS 

Cla8$  Description 

Class  extending  the  requirements  of  superdass_A . . . 

Qass  Interface 

DeGnes: 

mon_X :  definition 
tenn~  Y :  definition 

Encapsulated 

Information 

Encapsulates: 

superdass_A 

Objects  Derived 

List  object  names 

Ihtceability 

This  dass  encapsulates  the  fdlowing  requirements  . . . 

'IkbleS-6.  dassjC  Ibinplate 


Gass  Name 

dassjC 

Class  Description 

Class  constraining  the  requirements  of  superdass_A . . . 

Class  Interface 

Defines: 

term_Z:  definition 

Encapsulated 

Encapsulates: 

Information 

siq)erdass_A 

Objects  Derived 

List  object  names 

Traceability 

This  dass  encapsulates  the  following  requirements  . . . 
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5^  CLASS  MODEL  NOTATION  SUMMARY 

This  section  provides  a  sample  dass  definition  (Ihble  5-7)  and  a  summary  of  the  notation  (see 
Figure  5-15). 


Tkble  5-7.  Gass  Ibmplate  Summaiy 


Class  Name 

Provide  dass  name  preceded  by  ‘‘dass_’’ 

Class  Description 

Provide  a  description  of  the  dass. 

Class  Interface 

Defines: 

List  monitored  variables,  terms,  or  events. 

Encapsulated 

Information 

Encapsulates: 

list  monitored  variables,  controlled  variables,  terms,  modes,  events,  IN,  OUT, 
REQ,  NAT,  and  input  and  output  variables  or  classes. 

Objects  Derived 

List  objects  derived  from  ths  dass. 

Ibaceability 

Provide  traceability  information. 
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6.  Core  process  overview 

TIus  section  has  three  purposes.  Hrst,  it  introduces  you  to  the  CoRE  process.  It  outlines  each  of  the 
key  process  activities  describes  vdiat  information  you  need  for  each  activity  and  uhat  product  you 
produce.  After  finishing  this  section,  you  should  understand  the  overall  purpose  of  each  of  the  activi¬ 
ties  in  Core  and  how  they  work  togefoer  to  produce  a  onni^ete  software  requirements  specification. 

Second,  this  section  describes  the  relationship  between  the  idealized  CoRE  process  and  CoRE  in 
practice.  An  idealized  {x-ocess  assumes  a  perfectly  rational  developer  who  aWys  makes  the  right 
chdce  in  the  right  order.  This  ideal  process  produces  a  rational  progression  of  products  (top  down) 
b^innii^  with  the  system  spedfication  and  ending  with  the  software  requirements  specification.  A 
description  of  the  ideal  process  is  useful  because  it  fxovides  an  external  standard  to  guide 
development  and  it  serves  as  a  yardstidc  for  measuring  progress. 

An  idealized  process  description  tells  you  where  you  want  to  go,  but  it  is  not  always  the  best  guide  on 
how  to  get  there.  The  typical  develoixnent  process  is  iterative:  more  inside  out  than  top  down.  The 
maturity  and  level  of  detail  for  different  parts  of  the  specification  are  uneven,  and  the  captured  re¬ 
quirements  are  constantly  changing.  In  addition  to  the  ideal  process,  CoRE  provides  heuristics  and 
guidelines  to  guide  you  tluough  the  more  uncertain  stages  of  actual  development  Upon  finishing  this 
section,  you  shotild  understand  how  CoRE  helps  produce  ideal  products  from  a  real  pocess. 

Hnally,  this  section  serves  as  a  reference  for  the  CoREpocess.  It  provides  an  overview  of  each  of  the 
CoRE  activities,  including  the  inputs  to  the  activity,  the  goals,  and  the  products  poduced. 

6.1  THE  IDEALIZED  CoRE  PROCESS 

The  ideal  CoRE  pocess  is  a  sequence  of  activities  that  begins  with  a  system  requirements  (i.e., 
allocation  of  system  requirements  to  hardware  and  software  components  is  complete)  and  ends  with 
a  software  requirements  specification.  The  sequence  of  activities  is  organized  around  the  behavioral 
and  dass  models.  In  other  words,  each  step  gathers  some  part  of  the  behavioral  requirements  in  terms 
of  the  behavioral  model,  then  captures  that  information  in  the  dass  definitions.  The  process  is  ideal¬ 
ized  in  that  it  does  not  account  for  errors,  requirements  change,  unknown  requirements,  or  other  fac¬ 
tors  requiring  additional  iteration,  experimentation,  or  backtraddng.  A  schematic  showing  the 
activities  and  poducts  of  the  ideal  CoRE  pocess  is  shown  in  Figure  6-1. 
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6.1.1  Ii«i>niFYENviRONMran'AL  Variables 

Coab  Identify  candidate  environmental  variables  and  the  relations  among  them. 

The  overall  goal  is  to  identify  environmental  quantities  that  denote  the 
monitored  and  controlled  variables,  relationships  that  will  become  parts  of  the 
REQ  and  NAT  relations,  and  relationships  that  will  become  part  of  the 
generalization/specialization  structure.  Identify  likely  changes  and  their 
impacts  on  these  environmental  variables. 

b^uts  •  The  system  requirements 

•  System  interface  specifications 

•  Device  interface  specifications 

•  Other  sources  (including  people)  that  define  or  constrain  the  role  of 
the  software 

Purpose  The  purpose  of  this  activity  is  to  identify  the  environmental  quantities  with 

which  the  software  interacts  and  the  constraints  among  such  quantities.  You 
use  this  information  in  building  both  the  CoRE  behavioral  model  and  class 
model.  First,  the  physical  quantities  that  you  identify  help  in  determining  the 
environmental  variables  and  the  assodations  that  must  be  maintained  by  the 
REQ  or  NAT  relation  in  the  behavioral  model.  Second,  identifying  entities 
and  capturing  similarities  among  entities  aid  in  identifying  classes  and  the 
inheritance  relation  in  the  class  model. 

Produos  •  Information  model  (ERD,  attribute  matrix) 

•  Preliminary  NAT  relations 

•  Likely  changes  list 

Decisions  Decisions  about  required  behavior: 

•  Which  entities  and  relationships  described  in  the  system  specification 
and  other  sources  imply  software  requirements 

•  Which  entities  and  relationships  in  the  environment  represent 
constraints  on  the  required  behavior 

Decisions  about  packaging  the  software  specification: 

•  Which  requirements  might  change  and  how  likely  is  the  change 

•  Which  physical  quantities  are  related  and  should  be  thought  of  as 
attributes  of  the  same  entity  or  which  entities  are  inherently  related 
and  should  be  thought  of  as  instances  of  some  higher  level  entity 

•  Which  requirements  are  poorly  understood  or  represent  high  risk 
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6.1.2  Preuminary  Behavior  SpEancAXioN 

Coab  Identify  and  specify  the  monitored  and  controlled  variables.  Identify 

undesired  events  to  which  the  software  system  must  respond,  and  define 
monitored  variables  to  denote  them.  Identify  the  domain  and  scheduling  type 
for  each  controlled  variable.  Identify  modes. 

^uts  •  Information  model 

•  System  requirements 

Purpose  The  overall  purpose  of  this  activify  is  to  identify  enough  of  the  elements  of  the 

behavioral  model  to  make  ap|»^opriate  packa^ng  decisions  in  the  subsequent 
activity.  In  this  activity,  you  determine  and  capture  the  relationship  between 
the  software  and  its  environment  using  the  CoRE  behavioral  model.  You 
dedde  which  environmental  quantities  are  monitored,  controlled,  or  both. 
You  then  denote  the  quantities  by  monitored  and  controlled  variables. 

You  determine  what  information  about  the  monitored  variables  and  modes 
you  will  need  to  write  eadi  of  the  controlled  variable  functions.  You  decide 
how  many  mode  machines  are  needed  and  the  modes  and  possible  transitions 
for  each. 

Product:  •  Monitored  and  controlled  variable  definitions 

•  System  context  diagram 

•  Partial  REQ  definition  for  each  controlled  variable 

•  Initial  mode  machine  definitions 

Decisions  Decisions  about  required  behavior: 

•  Which  quantities  you  consider  monitored,  controlled,  or  both 

•  Which  undesired  events  the  software  system  must  respond  to 

•  Which  monitored  variables,  modes,  or  other  information  is  needed  to 
write  the  controlled  variable  functions 

•  Whether  each  controlled  variable  has  a  periodic  or  demand  scheduling 
requirement 

•  How  many  mode  machines  are  needed,  the  modes  in  each,  and  the 
allowed  transitions 

6.13  Class  Structuring 

Goab  Create  a  class  structure  to  address  your  packaging  goals.  Decide  how  the  parts 

of  the  behavioral  model  will  be  allocated  among  CoRE  classes.  Create 
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Purpose 


Products 


Decisions 


boundary,  mode,  and  term  dasses  based  on  your  packaging  goals.  Define  the 
class  interfoces  and  identify  dass  dependendes. 

•  Monitored  and  controlled  variable  definitions 

•  CoRE  information  model 

•  FErtial  REQ  definition  for  each  controlled  variable 

•  Likely  changes  list 

•  Initial  mode  machine  definitions 

In  Qass  Structuring,  you  make  the  padcaging  decisions  for  your  specification. 
You  define  a  set  of  dasses  that  will  contain  all  the  elements  of  the  CoRE 
behavioral  model.  You  determine  whidi  classes  will  be  further  decomposed 
into  additional  dasses.  You  determine  wfaidi  common  parts  of  the 
spedfication  will  be  represented  using  superdasses  and  subdasses.  You  define 
the  interface  for  eadi  dass  applying  the  prindples  of  abstraction  and 
information  hiding.  You  define  interface  terms  to  provide  the  information 
necessary  to  define  the  modes  and  controlled  variable  functions. 

•  Boundary,  mode,  and  term  class  interface  definitions,  induding  the 
encapsulation  structure  and  generalizadon/spedalization  structure 

•  Ifcrm  definitions 

•  Dependency  graphs 
Dedsions  about  required  behavior; 

•  Which  terms  are  needed 

•  What  mode  information  is  needed 

•  Which  classes  depend  on  what  information  defined  on  the  interf  es 
of  other  classes. 

Dedsions  about  packaging  the  specification: 

•  Which  boundary  classes  are  required  and  how  monitored  or  controlled 
variables  are  allocated  to  the  boundary  dasses 

•  Whidi  term  dasses  are  needed 


6.1.4  Detailed  Behavior  SpEciFiCAnoN 

Coals  Complete  the  dass  definitions  by  completing  the  specification  of  the 

controlled  variable  functions  and  timing  constraints  for  each  controlled 
variable.  Refine  the  dass  structure  to  be  consistent  with  the  behavioral  model 
needs. 
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•  Preliminary  NAT  relations 

•  Monitored  and  controlled  variable  definitions 

•  Class  interface  specifications,  including  modes  and  terms 

•  Controlled  variable  overviews 

•  System  requirements 

In  this  activity,  you  complete  the  specification  of  the  required  behavior  of  the 
software  by  completing  the  definition  functions  and  timing  constraints  for  eadi 
controlled  variable.  You  capture  the  behavioral  requirements  that  the 
software  must  meet  by  defining  the  values  eadi  controlled  variable  is  allowed 
to  assume  for  each  possible  state  of  the  system.  You  specify  any  timing  and 
accuracy  constraints  on  the  variables,  including  period  and  deadlines. 

Complete  controlled  variable  and  mode  machine  spedfications,  including: 

•  Controlled  variable  function  definitions 

•  Accuracy  constraints 

•  Timing  constraints 

•  NAT  relations 

•  Detailed  mode  machine  definitions 

•  Refined  dependency  graphs 

Decisions  about  required  behavior.  Fbr  each  controlled  variable: 

•  For  which  modes  is  the  value  of  the  controlled  variable  defined 

•  What  determines  the  required  value  in  each  mode 

•  What  is  the  tolerance  in  accuratty  for  each  possible  mode 

•  What  are  the  detailed  timing  constraints  governing  when  the 
controlled  variable  must  be  set 


6.1.5  Define  Hardware  Interface 

Goais  Define  the  software  system  inputs  and  outputs.  Define  the  IN  and  OUT 

relations. 


Inptos 


Boundary  class  definitions 
Device  interface  specifications 


r 


6.  Core  Process  Overview 


Purpose  Identify  how  the  software  system  inputs  and  outputs  can  be  used  to  establish 

the  value  of  monitored  variables  and  how  to  set  the  values  of  controlled 
variables.  You  complete  the  definitions  of  the  boundary  classes  by  specifying 
the  input  and  output  variables  and  defining  the  IN  and  OUT  relations.  Define 
any  additional  constraints  on  the  presentation  of  monitored  and  controlled 
quantities  (e.g.,  specify  the  requirements  for  user  interfaces). 

ProduOs  •  Input  and  output  variable  definitions 

•  IN  and  OUT  relations 

Decisions  Decisions  about  required  behavior: 

•  What  inputs  can  the  software  use  to  determine  the  value  of  each 
monitored  variable;  how  can  the  software  use  the  inputs  to  determine 
the  value  (the  IN  relation) 

•  What  outputs  can  the  software  use  to  set  the  value  of  each  controlled 
variable;  how  can  the  software  use  the  outputs  to  set  the  value  (the 
OUT  relation) 

Decisions  about  packaging  the  specification: 

•  In  which  class  should  each  input  and  output  variable,  IN,  or  OUT 
relation  be  defined 


6.2  Core  in  practice 

In  practice,  you  are  concerned  with  both  developing  the  requirements  specification  and  managing  the 
development.  The  ideal  CoRE  process  proceeds  systematically  from  system  requirements  to  the  soft¬ 
ware  requirements  specification,  adding  detail  in  each  activity.  Every  decision  must  be  made  individu¬ 
ally,  and  the  specification  is  built  up  as  a  sequence  of  detailed  decisions  and  iterations  on  those 
decisions.  To  provide  useful  guidance  in  the  day-to-day  practice  of  developing  a  specification,  a  meth¬ 
od  should  help  answer  two  basic  questions  at  any  given  level  of  detail:  “What  should  I  do  next?”  and 
“How  do  I  know  when  I  am  done  (or  done  enough)?”  CoRE  helps  answer  these  questions  through 
its  behavioral  model  because,  for  a  given  set  of  controlled  variables,  the  model  determines  exactly 
what  kinds  of  information  are  needed  to  write  a  complete  CoRE  specification. 

Specification  development  also  tends  to  be  highly  concurrent,  asynchronous,  and  subject  to  change. 
Several  people  typically  will  be  developing  the  requirements  at  the  same  time.  Some  parts  of  the  re¬ 
quirements  will  be  well  understood  and  can  be  captured  in  detail,  while  other  parts  are  fuzzy  or  highly 
likely  to  change.  To  help  manage  development,  CoRE  provides  guidance  and  facilities  for  breaking 
a  specification  into  parts  that  can  be  developed  or  changed  independently. 

6.2.1  Specifying  Required  Behavior 

The  behavioral  model  drives  the  specification  of  required  behavior.  Because  the  model  is 
standardized,  the  general  set  of  questions  that  must  be  answered  to  provide  a  complete  specification 
is  known  in  advance.  Further,  because  the  model  is  known  in  advance,  CoRE  provides  templates  to 
help  capture  the  details  of  the  specification. 
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The  detailed  guidance  provided  by  CoRE  is  keyed  to  the  individual  controlled  variables.  When  you 
decide  what  the  controlled  variables  will  be,  the  same  basic  set  of  questions  must  be  answered  for  each 
one.  When  those  questions  have  been  answered  for  one  variable,  its  specification  is  complete.  When 
they  have  been  answered  for  all  of  the  variables,  the  entire  specification  is  complete.  If  any  of  the  an¬ 
swers  are  unknown,  this  will  be  clear  fi^om  the  format  and  content  of  the  specification.  The  CoRE  tem¬ 
plates  show  explicitly  which  parts  of  the  specification  are  incomplete.  TTie  following  summarizes  the 
sequence  you  follow  in  specifying  the  required  behavior  of  a  controlled  variable.  More  detailed 
guidance  is  provided  in  the  process  section. 

1.  Define  Ok  Identify  a  distinct  environmental  quantity  (e.g.,  the  state  of  a  valve)  controlled 

controlled  by  the  software  system.  Create  a  controlled  variable  denoting  the  quantity,  and 

variables.  define  the  name  of  the  variable,  physical  interpretation,  type  and  range  of 

values,  and  any  other  relevant  NAT  constraints,  such  as  maximum  rate  of 
change. 

Additional  Guidance:  Controlled  variable  template  (Ihble  4-2) 

2.  Define  the  Identify  the  quantities  in  the  environment  that  the  software  system  will  ne^ 

monitored  to  track.  For  each  relevant  quantity,  create  a  monitored  variable  modeling  the 

variables.  quantity  and  define  the  name  of  the  variable,  physical  interpretation,  type  and 

range  of  values,  and  any  other  relevant  NAT  constraints,  such  as  maximum 
rate  of  change.  Figure  6-2  illustrates  the  results  of  steps  1  and  2. 


Additional  Guidance:  Monitored  variable  template  (Ihble  4-2) 


Boundary  Class  Definition — ^Monitored 

Side 

Mode  Class 

Boundary  Class  DeGnition — Controlled 

Side 

Monitored  Variable  Definftioii 

Nameiype  Interpretafiott 

EiielLevel  Length  Level  of  liiel... 

KATCoustrafottB 

0.0<  FbelLevelOOcm 

Controlled  Variable  DeOnition 

Name  '!)[^  Interpretation 

LowAlanu  Alarm  Blinking  Indicator-...  ^ 

NAX  Cottsfcainu:  None 

Figure  6-2.  Results  of  Steps  land  2 

3.  Define  the  Define  the  required  controlled  variable  behavior  as  a  function  giving  ideal 

controlled  behavior.  First,  identify  in  which  states  of  the  system  the  function  must  be 

variable  defined  (i.e.,  the  domain  of  the  function).  If  the  behavior  changes  as  a  function 

Junction  of  the  monitored  variable’s  history,  identify  or  define  the  relevant  mode 

domain.  machines. 

Additional  Guidance:  Controlled  variable  function  template  (Section  4.3.1) 

4.  D^ine  mode  Where  the  value  of  the  controlled  variable  is  a  function  of  the  monitored 

machine.  variable’s  history,  define  a  mode  machine  to  model  the  state  and  state  changes. 

Identify  the  relevant  states  (i.e.,  those  that  partition  the  domain  of  the 
controlled  variable  function)  and  model  these  with  the  modes  of  a  mode  class. 
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Define  the  transitions  between  classes  in  terms  of  dianges  in  monitored 
variables  (events).  Figure  6-3  illustrates  the  results  of  steps  3  and  4. 

Additional  Guidance:  Finite  state  machine  model  for  mode  machines 
(Section  4.1.5) 


Figure  6-3.  Results  of  Steps  3  and  4 

5.  Ident^the  For  each  mode,  identify  under  which  circumstances  the  controlled  vadable 

conditions.  takes  on  which  possible  values.  Equivalently,  you  must  fill  in  each  cell  of  the 

controlled  variable  function  table;  this  defines  the  behavior  in  every  possible 

state  of  the  monitored  variables. 

Additional  Guidance:  Controlled  variable  fimetion  template  (Section  4.1~S) 

6.  Define  the  Establish  the  range  of  variation  allowed  in  the  controlled  variable  value  in  each 

controlled  possible  state,  and  represent  this  as  a  tolerance  in  accuracy.  Establish  the 

variaNe  range  of  variation  allowed  in  the  timing,  and  define  the  timing  and  accuracy 

tolenaux.  constraints.  Figure  6-4  illustrates  the  results  of  steps  5  and  6. 

Additional  (  uidance:  Controlled  variable  function  template  (Section  4.1.5) 

7.  Define  input  Identify  the  inputs  used  to  determine  the  values  of  the  monitored  variables 

and  ou^  used,  and  define  an  input  variable  for  each.  Identify  the  outputs  used  to  set  the 

variaUes.  value  of  the  controlled  variable,  and  define  an  output  variable  for  each. 

Additional  Guidance:  Input  and  output  variable  templates  (Ibble  11-1) 

8.  D^ine  die  IN  For  each  monitored  variable,  specify  how  the  value  of  that  variable  can  be 

and  OUT  determined  from  the  input  variables.  Define  a  relation  showing  how  the 

relations.  required  value  of  the  controlled  variable  can  be  set  by  assigning  values  to  the 

output.  Figure  6-5  illustrates  the  results  of  steps  7  and  8. 

Additional  Guidance:  IN  and  OUT  relation  tables  (Section  11.3.3) 
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Figure  6-4.  Resuit  of  Steps  S  and  6 


Boundary  Class  Definition — Monitored 
Side 


Mode  Class 


Boundary  Class  Definition — Controlled 
Side 
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Figure  6-S.  Results  of  Steps  7  and  8 
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6^2  Iterahon  Among  Core  AcnvniES 

In  practice,  you  must  iterate  the  CoRE  activities  as  you  reflne  your  understanding  of  the  behavioral 
requirements,  the  implications  of  your  packaging  dedsions,  or  as  requirements  diange.  This  section 
discusses  how  you  will  iterate  between  the  major  CoRE  activities.  Where  additional  guidance  is  need¬ 
ed  on  iteration  within  an  activity,  this  is  given  in  the  relevant  section  of  the  guidebook.  In  general,  it 
is  assumed  that  you  will  iterate  as  necessary  within  an  activity. 

The  primary  reason  for  iteration  among  CoRE  activities  is  to  resolve  discrepancies  between 
packaging  dedsions  (dass  structuring)  and  behavioral  modeling.  The  driving  prc^lem  is  that  you 
cannot  finalize  dedsions  about  the  class  structure  until  you  understand  what  information  is  needed 
by  which  dasses  to  complete  the  detailed  behavior  spedfication.  Conversely,  you  will  not  be  able  to 
complete  the  spedfication  of  the  behavioral  model  without  making  dedsions  about  what  information 
the  dass  structure  will  encapsulate  and  vhat  information  will  be  public.  Thus,  you  will  ^ically  spedfy 
part  of  the  behavioral  model,  do  some  class  structuring,  evaluate  the  class  structuring,  then  return  to 
spedfying  the  behavioral  model  until  the  open  issues  become  suffidently  resolved  to  stabilize  the 
spedfication. 

In  part,  this  iteration  is  captured  by  the  major  CoRE  activities.  The  goal  of  Preliminary  Behavior 
Specification  is  to  identify  enough  of  the  components  of  the  behavioral  model  to  make  sensible  pack¬ 
aging  decisions.  Detailed  Behavior  Spedfication  revisits  the  class  structuring  dedsions.  In  addition, 
you  will  iterate  as  follows: 

•  You  iterate  between  Preliminary  Behavior  Spedfication  and  Class  Structuring.  As  you  begin 
to  understand  what  information  you  wish  to  encapsulate  in  the  classes  and  what  the  form  of 
the  class  interfaces  will  be,  you  may  revisit  and  refine  the  information  about  the  controlled 
variables  functions  you  gathered  in  Preliminary  Behavior  Specification. 

•  You  iterate  between  Class  Structuring  and  Detailed  Behavior  Spedfication.  As  you 
understand  the  detailed  requirements,  you  may  determine  that  you  have  encapsulated 
information  needed  by  other  classes.  This  will  force  you  to  revisit  Class  Structuring. 

Overall,  much  of  the  iteration  will  involve  what  information  must  appear  on  the  class  interfaces.  This 
is  because  there  is  an  inherent  conflict  between  the  goals  of  class  structuring  and  the  goals  of  the  behav¬ 
ioral  model.  Class  structuring  seeks  to  reduce  complexity  and  dependent^  by  encapsulating  as  much 
information  as  possible;  however,  the  behavioral  model  cannot  be  completed  without  suffident 
information,  lb  balance  these  concerns  requires  iteration  between  these  activities. 

Particularly  affected  by  the  iteration  is  the  choice  of  terms  (expression  of  monitored  variables)  defined 
in  the  class  interfaces.  Tbrms  are  one  of  the  primary  vehicles  for  abstracting  from  details  while  provid¬ 
ing  exactly  the  information  needed  to  write  the  behavioral  model.  Because  of  this,  the  ideal  process 
description  allocates  the  activify  of  creating  terms  primarily  to  Class  Structuring.  However,  because 
you  will  write  the  behavioral  spedfication  using  those  terms,  you  will  typically  revisit  the  choice  of 
terms  and  their  definitions  in  Preliminary  Behavior  Spedfication,  Class  Structuring,  and  Detailed 
Behavior  Spedfication. 

In  spite  of  the  necessary  iteration,  your  goal  is  to  stabilize  as  much  of  the  class  structure  as  possible 
during  the  Gass  Structuring  activity.  It  is  the  fact  that  dasses  have  stable  and  well-defined  interfaces 
that  will  allow  independent  development  of  the  individual  classes. 
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6.23  Managing  Requirements  Development 

The  Core  method  allows  you  to  divide  a  requirements  specification  into  a  set  of  distinct  and  relatively 
independent  parts.  At  the  systems  level,  you  can  divide  the  problem  into  distinct  subsystems.  You  di¬ 
vide  the  software  specification  into  a  set  of  classes.  Classes  may  encapsulate  additional  classes  and 
class  dependencies.  These  provide  the  packaging  facilities  needed  to  manage  development  issues. 
While  the  specific  goals  and  necessary  techniques  depend  on  what  must  be  managed,  the  general  ap¬ 
proach  is  to  use  the  class  structure  to  encapsulate  parts  of  the  specification  that  must  be  treated  as  a 
unit,  for  example: 

•  Concurrent  Deveiopment.  You  will  often  want  to  break  the  specification  task  into  parts,  each 
being  a  distinct  work  assignment.  You  can  use  the  class  structure  to  accomplish  this.  When  you 
define  the  interface  of  a  class,  you  can  only  use  information  defined  in  the  interfaces  of  other 
classes  to  develop  the  encapsulated  part.  One  or  more  classes  can  be  allocated  as  a  work  as¬ 
signment  and  completed  independently.  Where  there  must  be  changes  to  a  class  interface,  the 
Core  dependency  graph  allows  you  to  determine  which  parts  of  the  specification  and,  hence, 
which  work  assignments  are  affected. 

•  Risk  Mutation.  You  will  want  to  develop  different  parts  of  your  specification  to  different  levels 
of  detail  at  different  times.  Where  parts  of  the  requirements  are  considered  higher  risk,  you 
may  proceed  to  detailed  specification,  design,  or  implementation  to  mitigate  that  risk.  Fbr  ex¬ 
ample,  you  might  develop  part  of  the  software  to  better  understand  the  problem  or  to  ensure 
that  your  solution  is  satisfactory.  In  some  cases,  one  part  of  the  requirements  may  be  better 
known  or  better  understood  than  another.  In  such  cases,  the  class  structure  can  be  defined  so 
the  parts  that  will  be  developed  to  detail  are  encapsulated  in  one  or  more  classes. 
Development  of  these  classes  can  then  proceed  independently  of  the  rest  of  the  software. 

•  Fiizxy  or  Changeable  Requirements.  Particularly  in  the  initial  stages  of  development,  some 
requirements  will  be  fimy  and  others  will  be  highly  volatile  as  the  software  develops.  You  will 
want  to  reduce  the  likelihood  that  the  refinement  of  fxsxiy  requirements  or  changes  in  volatile 
requirements  affects  other  parts  of  the  specification.  In  CoRE,  you  can  encapsulate  fuzzy  or 
volatile  requirements  in  a  class,  putting  only  the  most  stable  requirements  on  the  class  inter¬ 
face.  Then,  changes  to  those  requirements  will  be  confined  to  the  defining  class.  Conversely, 
you  may  choose  to  isolate  and  develop  a  part  of  the  software  that  is  considered  stable.  Either 
approach  can  be  used  in  shaping  an  evolutionary  development  process  (e.g.,  specify 
best-defined  first  or  identify  and  specify  high-risk  areas). 
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This  guidebook  assumes  that  you  start  the  software  requirements  activity  with  a  set  of  system 
requirements  that,  from  the  standpoint  of  creating  a  CoRE  specification,  are  relatively  unstructured, 
inconsistent,  and  incomplete.  In  addition,  the  guidebook  assumes  that  relationships  among  the  candi¬ 
date  environmental  variables  are  not  simple  and  well  understood;  e.g.,  you  may  know  that  related  sets 
of  candidate  environmental  variables  diaracterize  distinct  things  but  are  not  sure  that  the  things 
should  be  thought  of  as  instances  of  the  same  entity. 

The  Identify  Environmental  Variables  activity  focuses  on  informally  identifying,  collecting,  and 
organizing  the  information  you  will  need  to  create  a  CoRE  specification.  In  particular,  it  focuses  on 
identifying  candidate  environmental  variables  and  the  relationships  among  them.  The  creation  of  an 
information  model  drives  this  activity,  where  an  information  model  nominally  consists  of  a  set  of  enti¬ 
ties,  attributes  of  the  entities,  and  the  relationships  among  instances  of  the  entities.  However,  the  in¬ 
formation  model  is  not  a  part  of  a  CoRE  specification;  it  is  solely  used  to  help  you  gather  and  organize 
the  information  you  need  to  aeate  the  formal  CoRE  specification  (described  in  Sections  8  through 
11). 

You  use  the  information  model  to  populate  both  the  CoRE  behavioral  model  and  class  model.  In  the 
behavioral  model,  you  consider  the  entity  attributes  to  determine  which  environmental  quantities  will 
be  captured  as  monitored  variables  and  controlled  variables.  You  also  gain  a  preliminary  understand¬ 
ing  of  the  information  you  need  to  define  the  REQ  (which  monitored  variables  determine  the  required 
value  of  each  controlled  variable)  and  NAT  relations  (how  the  environment  of  the  software  system 
constrains  the  values  that  the  environmental  variables  can  assume). 

In  the  dass  model,  you  consider  whidi  variables  are  inherently  related  and  should  be  defined  in  the 
same  CoRE  class.  Also,  you  identify  which  variables  should  be  thought  of  as  spedalizations  of  a  more 
general  variable  (described  by  the  generalization/spedalization  relation). 

7.1  GOALS 

The  goal  of  this  activity  is  to  identify  candidate  environmental  variables  (attributes)  and  to  understand 
and  record  how  they  and  the  things  in  the  environment  that  they  characterize  (entities)  are  related. 
In  this  activity,  you  want  to  gather  and  organize  information  so  that  you  have  a  complete  list  of: 

•  Physical  quantities  that  you  use  to  spedfy  the  software  requirements  and  the  definitions  of  the 
attributes  that  denote  them 

•  Entities  in  the  environment  that  the  attributes  characterize  and  the  subdass  and  s^egation 
relations  among  the  entities  to  organize  the  information 
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•  Relations  among  the  entities  that  constrain  the  values  that  their  attributes  can  assume 

•  Likely  changes  and  their  impact  on  the  environmental  variables 

7 J  ENTRANCE  CRTTERU 

One  or  more  sources  of  information  about  the  system^  its  requirements,  and  its  design  are  required 
to  perform  this  activity.  The  following  are  tyfMcal  sources  of  this  information: 

•  System  requirements  specifications 

•  ^tem  interface  specifications 

•  Tbchnical  descriptions  of  devices  that  are  part  of  the  software  system 

•  Access  to  domain  e^rts 

Specification  documents  vary  considerably  in  format  and  degree  of  formality  depending  on  the  nature 
of  the  project.  Whatever  the  organization  and  level  of  detail  of  the  systems-level  specification  docu¬ 
ments,  it  is  important  to  identify  supplementary  sources  of  information.  A  technit^  manual  for  any 
device  to  which  the  software  must  interface  may  be  a  oritical  source  of  information.  Furthermore,  do^ 
main  experts,  who  are  familiar  with  the  engineering,  physical  science,  and  human  factors  of  the  prob¬ 
lem  domain,  are  often  needed  to  provide  supplementary  information.  In  some  projects,  they  may  be 
the  primary  source  of  information. 

73  ACnVITIES 

The  Identify  Environmental  Variables  activity  is  composed  of  the  following  subactivities: 

•  The  Identify  and  Define  Attributes  subactivity  guides  you  in  identifying  the  physical  quantities 
(environmental  variables)  that  are  relevant  to  describing  the  behavior  of  the  softvt^e. 

•  The  Identify  Entities  subactivity  guides  you  to  organize  the  attributes  by  identifying  the 
entities  in  the  environment  that  the  attributes  diaracterize. 

•  The  Identify  Generalization/Specialization  Relation  subactivity  guides  you  in  commonality  on 
the  values  of  the  attributes. 

•  The  Identify  Aggregation  Relation  subactivity  guides  you  on  the  values  of  the  attributes. 

•  The  Identify  Application-Spedfic  Relation  subactivity  guides  you  in  constraints  on  the  values 
of  the  attributes. 

•  The  Identify  Likely  Requirements  Changes  and  Associated  Variables  subactivity  guides  you 
to  identify  likely  changes  in  the  system-level  requirements  and  to  relate  each  change  to  the 
environmental  variables. 

The  Core  information  model  serves  a  different  purpose  than  a  traditional  data  model  (like  the  model 
outlined  by  Chen  [1976]).  The  emphasis  of  this  activity  is  to  identify  the  environmental  variables  and 
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their  constraints,  net  imj^cations  of  data  integrity,  information  retrieval,  and  data  manipulation.  The 
Core  information  model  also  differs  in  that  concepts,  such  as  key  attributes,  cardinality,  and  third 
normal  form,  are  not  considered.  The  common  diagraming  technique  for  capturii^  an  information 
model  is  an  ERD,  and  building  one  of  these  for  CoRE  is  optional.  You  could  cai^ure  relationships 
among  the  attributes  in  an  attribute  matrix.  The  examples  given  in  this  section  are  illustrated  using 
the  grafdiics  for  an  ERD  and  an  attribute  matrix  (see  Section  5.1). 

Note  that  the  sequencing  of  activities  does  not  follow  an  idealized  top-down  process.  In  such  an 
idealized  process,  for  ocample,  entities  would  be  identified  first,  and  then  the  attributes  of  eadi  entity 
would  be  identified.  The  activities  are  shown  here  in  more  of  a  bottom-up  fashion,  which  is  apfn'opri- 
ate  because  the  sources  of  information  for  performing  the  activities  are  not  likely  to  be  organized  to 
best  support  a  top-down  process.  This  ordering  of  activities  assumes  that  it  will  be  easier  for  you  first 
to  identify  the  attributes  from  the  information  avaUable  to  you  than  to  identify  the  entities  first.  If  you 
think  it  will  be  easier  to  identify  the  entities  first,  you  should  identify  the  attributes  after  you  have 
identified  the  entities  or  perform  the  activities  coiKnurently. 

73.1  loENiiFy  AND  Define  ArnuBum 

This  activity's  goal  is  to  identify  physical  quantities  that  are  relevant  to  describing  the  required 
behavior  of  the  software  and  to  define  an  attribute  to  denote  each  quantity.  The  software  may  monitor 
or  control  these  quantities,  or  their  values  may  influence  quantities  that  the  software  does  monitor 
or  control.  It  is  not  necessary  to  make  such  distinctions  in  t^  activity;  rather  you  simply  identify,  de¬ 
fine,  and  collect  all  of  the  attributes.  It  is  also  not  necessary  in  this  activity  to  ensure  that  the  attributes 
are  independent  of  one  another,  i.e.,  that  the  value  of  one  cannot  be  computed  from  the  value  of 
another. 

Likely  sources  of  attributes  are: 

•  Variable  properties  of  physical  objects  in  the  problem  scope,  e.g.,  positions,  velocities,  and 
temperatures. 

•  Physical  quantities,  sudi  as  dimensions  of  physical  objects. 

•  Information  passed  across  the  interface  of  physical  devices,  e.g.,  device  status  or  device 
commands.  Environmental  variables  fypically  abstract  the  interfaces  of  physical  devices.  We 
look  at  physical  devices  because  they  give  us  insight  into  which  physical  quantities  the  software 
system  can  monitor  and  control. 

•  Information  provided  by  or  supplied  to  a  human  user,  e.g.,  user  commands  or  user  displays. 

•  Undesired  events,  e.g.,  failures  of  components  of  the  system  or  of  the  software  system  itself, 
to  which  the  software  system  is  requir^  to  respond. 

Examples  In  the  FLMS  problem,  variable  properties  indude  the  level  and  flow  rate  of  fuel  in  the 
tank.  Information  passed  aCTOss  device  interfaces  includes  the  signal  that  opens  or  doses  the  pump 
relay.  User  interface  information  indudes  the  reset  signal  provided  by  the  user  via  a  push  button. 
Because  the  FLMS  is  a  safety  system,  the  failure  of  it  is  an  important  concern  and  is  denoted  by 
the  attribute  Failure  of  FLMS.  Ihble  7-1  provides  a  more  complete  list  of  attributes  for  the  FLMS. 
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IkUe  7-1.  Sample  Fliel  Monitoriiig  ^tem  Attribute 


1.  ShutdowoRelay 

2.  Power 

3.  Failttre  of  FLMS 

4.  Fbel  flow  rate 

5.  Fbel  level 

6.  Level  too  h)^ 

7.  Level  too  low 

8.  Reset 

9.  Selftest 

10.  F\iel  level  display 

11.  AudiUe  alarm 

12.  Level  too  low  alarm 

13.  Level  too  high  alarm 


Define  the  attributes  that  you  have  identified  to  precisely  communicate  your  decisions  to  other 
engineers.  Clearly  describe  the  association  between  the  physical  quantity  and  the  attribute  that  de¬ 
notes  it  Describe  the  association  between  what  can  be  ol^erved  from  a  view  external  to  the  software 
system  and  what  value  the  attribute  will  assume  (see  Ihbles  7-2  and  7-3).  In  Section  8.3.1,  you  expand 
upon  this  definition  for  attributes  that  you  decide  are  environmental  variables.  You  may  decide  that 
you  understand  the  software  system  and  its  environment  well  enough  that  you  already  know  which  of 
the  attributes  are  monitored  and  which  are  controlled  variables.  In  this  case,  you  may  want  to  provide 
the  more  complete  and  precise  definitions  of  attributes  that  Section  8.3.1  describes  for  environmental 
variables. 


Ikble  7-2.  Sample  Definition  of  an  Enumerated  Attribute 


Attribute 

Definition 

SbtttdownRelay 

The  fuel  pump  shutdown  relay  is  closed. 

The  fuel  pump  shutdown  relay  is  open. 
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Ikble  7-3.  Sample  Definition  of  a  Numeric  Attribute 

Attribute 

Definituma 

Fuel  Level 

Level  of  fuel  in  the  tank,  in  centimeters  (cm),  along  the  vertical  ads  on 
the  left  side  of  the  tank,  S  cm  from  the  front  edge.  The  level  is  measured 
with  respect  to  the  scale. 

132  iDENnFY  Enttiies 

Hie  goal  of  this  activity  is  to  organize  the  attributes  by  identifying  the  entities  in  the  environment  that 
the  attributes  characterize.  The  entities  are  often  physical  things  (e.g.,  engines,  aircraft,  radios,  and 
other  equipment),  but  they  may  include  the  roles  play^  by  persons  or  organizations  (e.g.,  pilot,  opera¬ 
tor),  incidents,  processes,  interactions  (e.g.,  the  mixing  of  dyes  in  a  vat,  a  near-collision  of  two  aircraft), 
and  specifications  (e.g.,  a  specification  of  the  attribute  values  that  distinguish  pickup  trucks  from 
minivans)  (Shlaer  and  Mellor  1988). 

In  addition  to  the  attributes,  consider  the  following  when  identifying  entities: 

•  Devices  that  are  monitored  or  controlled  by  the  software 

•  Physical  entities  that  are  “observed”  via  sensors  1^  the  software 

•  People  or  systems  that  receive  information  from  or  provide  information  to  the  software 

•  The  software  system  itself  or  possibly  its  subsystems 

Associate  each  attribute  with  the  entify  that  it  characterizes.  You  may  identify  entities  that  no  attribute 
diaracterizes.  When  you  do  so,  look  for  attributes  you  have  overlooked  to  characterize  the  entities, 
lb  establish  a  context  for  the  software  ^tem,  you  may  want  to  include  in  your  information  model 
entities  characterized  by  no  attributes. 

Ihble  7-4  lists  the  FLMS  entities  and  the  attributes  that  diaracterize  each  of  them.  Consider  whether 
there  may  be  multiple  instances  of  any  of  the  entities  that  you  have  identified  (e.g.,  four-engine  entities 
on  an  aira*aft).  Indicate  multiple-entify  instances  recording  the  number  of  instances  with  the  entity. 

The  entities  that  you  have  defined  represent  a  relatively  unstructured  set  of  information.  Organize 
the  entities  by  examining  them  and  the  specifications  that  serve  as  inputs  to  this  activity  to  determine 
how  the  entities  are  related  to  one  another  by  generalization/spedalization,  aggregation,  and 
application-specific  relations. 

133  Identify  Generauzation/Speciauzation  Relation 

The  goal  of  this  activity  is  to  identify  similarities  among  entities  and  record  this  information  via  a 
generalization/spedalLmtion  relation.  The  generalization/specialization  relation  indicates  that  one 
entity  is  an  instance  of  a  more  abstract  enti^  e.g.,  the  reset  and  selftest  switches  are  instances  of  a 
more  general  two-position  switch  (see  Figure  7-1).  This  relation  allows  you  to  record  essential  similar- 
ify  among  entities  in  the  system’s  environment  Recording  this  similarify  will  be  useful  when  you  try 
to  understand  what  changes  are  likely  to  occur  together. 
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Table  7-4.  Sample  Fuel  Level  Monitoring  System  Entities  and  Attributes 


Entity 

Attribute 

Pump 

• 

ShutdownRelay 

• 

Power 

FLMS 

•  Failure 

FUellhnk 

• 

Fuel  level 

• 

Level  too  high 

• 

Level  too  low 

Fbel 

•  Fuel  flow  rate 

Operator  Interface 

• 

Instances 

• 

Reset 

• 

Selftest 

• 

Fuel  level  display 

• 

Audible  alarm 

• 

Level  too  low  alarm 

• 

Level  too  high  alarm 

7J.4  Idemhey  Aggregation  Remhon 

The  goal  of  this  activity  is  to  provide  structure  and  information  that  the  software  must  maintain  that 
belongs  to  an  aggregate  as  opposed  to  an  individual  part.  The  aggregation  relation  indicates  that  one 
or  more  entities  are  part  of  another  entity  (e.g.,  engines,  wings,  and  fuselage  are  part  of  an  aircraft). 
This  relation  allows  you  to  record  information  that  may  be  helpful  in  understanding  the  system’s  envi¬ 
ronment  and  structuring  your  description  of  it.  This  relation  may  lead  you  to  identify  additional  enti¬ 
ties  that  aggregate  entities  you  have  already  identified.  Figure  7-1  includes  the  entities  Shipboard  Fuel 
^tem  (an  aggregate  of  the  entities  already  identified)  and  Operator  Console  (an  aggregate  of  Alarm 
and  Display). 

7.3,5  Identify  AppucATiON-SPEcinc  Relation 

The  goal  of  this  activity  is  to  develop  an  understanding  of  constraints  on  the  values  of  attributes  that 
the  system’s  environment  imposes  or  that  the  tystem  is  required  to  impose.  In  subsequent  activities, 
you  will  expand  on  and  refine  this  information  to  create  the  NAT  and  REQ  relations,  respectively.  In 
this  activity,  you  will  not  attempt  to  distinguish  between  the  two  or  attempt  to  specify  precisely  what 
those  constraints  are.  Rather,  you  will  decide  which  attribute  values  may  be  affected  by  the  values  of 
which  other  attributes. 
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Shfboard  Fuel 
Syttem 


is_pait  of 
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Pump 

•  ShutdownRelay 

•  Power 


•  Fiilure 


is_part_<rf 


Fuelunk 

•  FuelLevel 

•  Level  Too  High 

•  LevelToolLow 


Selftest 


Switch 


Poshioa 


Operator  mteiface 


is_part_of 


Alarm 


•  Fuel  Flow  Rate 


Operator  Console 


is_part  of 


FuelLevel 


High  Alarm 


Low  Alarm 


Audible  Alarm 


mgure  7-1.  Information  Model  for  the  Fhel  Level  Monitoring  System 

Examine  the  entities  and  attributes  that  you  have  created,  looking  for  pairs  of  attributes  in  which  the 
value  of  one  determines,  prescribes,  or  constrains  the  value  of  the  other.  For  each  pair,  create  a  rela¬ 
tion  between  the  entities  ^ai  acterized  by  the  attributes.  If  the  attributes  diaracterize  the  same  entity, 
the  entity  will  be  related  to  itself.  Annotate  the  graphical  information  model  with  the  relation,  or  use 
an  attribute  matrix  to  record  the  attributes  constrained  by  the  relation  (see  Tkble  7-5). 


Ibble  7*5.  Fbel  Level  Monitoring  ^tem  Attribute  Matrix 
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Examples  Figure  7-2  shows  an  example  of  a  constraint  between  two  entities.  Weapon  and  'Girget. 
This  figure  shows  the  relationship  between  Weapon  and  Thrget,  where  a  weapon  is  designated  to 
a  target. 


Figure  7-2.  Weapon  and  ThTget  Constraint 

73.6  IDE^^1FyIJI□BLYREQUIREME^^:«OaANGESA^^D  Associated  Variables 

The  goal  of  this  activity  is  to  identify  likely  changes  in  system-level  requirements  and  to  relate  each 
diange  to  its  impact  on  the  potential  environmental  variables  (i.e.,  the  attributes  that  you  have  identi¬ 
fied).  Create  a  list  of  the  likely  changes  that  you  identify.  You  will  use  this  list  of  likely  dianges  with 
other  system-level  information  available  to  you  to  allocate  the  environmental  variables  into  dasses. 

Consider  how  the  potential  environmental  variables  that  you  developed  might  change.  For  example, 
in  the  FLMS  problem,  human  factor  issues  can  cause  dianges  to  the  variables  that  describe  the  in¬ 
formation  that  the  system  provides  to  the  user:  Audible  Alarm,  High  Alarm,  Low  Alarm,  and  Fuel 
Level  Display.  Such  a  likely  change  can  be  described  by  the  following  description: 

The  information  that  the  system  provides  to  the  user  and  how  that  information  is  presented 
is  likely  to  change. 

Also,  consider  information  provided  by  the  following  in  developing  the  list  of  likely  changes: 

•  System  requirements  spedfications 

•  System  interface  spedfications 

•  Ibchnical  descriptions  of  the  devices  with  which  the  software  interacts 

•  Discussions  with  domain  experts 

In  particular,  look  for  areas  in  which  knowledge  of  the  system  and  its  environment  appears  vague  or 
contradictory.  For  otample,  in  the  case  of  FLMS,  if  some  of  the  experts  discuss  unsafe  conditions  in 
terms  of  the  fuel  level  in  the  tank  and  others  discuss  unsafe  conditions  in  terms  of  the  volume  of  fuel 
in  the  tank,  you  could  consider  this  desaiption  a  likely  change: 

How  the  FLMS  will  determine  unsafe  conditions  is  likely  to  change. 

An  mample  of  the  likely  change  list  from  the  FLMS  follows: 

1.  The  means  for  informing  the  operator  of  the  FLMS  state  (i.e.,  the  alarms  and  displays)  is 
expected  to  change  independently  of  how  the  system  recognizes  unsafe  conditions. 

2.  Level  display  is  likely  to  change  independently  of  the  rest  of  the  system. 

3.  High  and  low  alarms  are  unlikely  to  change  independently  of  one  another.  They  are  likely  to 
diange  independently  of  the  rest  of  the  system. 
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4.  The  physical  diaracteristics  of  the  push  buttons  are  unlikely  to  change  independently  of  one 
another.  They  are  likely  to  change  independently  of  the  rest  of  the  system. 

5.  The  exact  levds  that  are  considered  out  of  range  nuQTchai^  from  one  installatkxi  of  the  FLMS  to 
another  or  over  time.  They  are  likdy  to  change  independent^  of  the  rest  of  the  ^rstem. 

7.4  EVALUATION  CRTTEIUA 

Evaluate  the  products  of  this  activity  by  answering  the  following  questions: 

•  Have  you  completed  the  definitions  of  each  entity,  attribute,  and  relationship? 

•  Have  all  relevant  relationships  among  entities  been  identified? 

•  Have  likely  requirements  changes  and  associated  entities  or  attributes  been  identified? 

7.5  EXIT  CRITERIA 

You  have  completed  this  activity  when  you  can  answer  “yes”  to  each  of  the  questions  in  Section  7.4 

and  you  have  developed  the  following  products: 

•  Candidate  list  of  environmental  variables 

•  Candidate  list  of  the  information  needed  to  determine  the  required  value  of  each  controlled 
variable 

•  Candidate  list  of  how  the  environment  of  the  system  c  nstrains  the  values  that  the 
environmental  variables  can  assume 


Likely  change  list 
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In  the  Preliminary  Behavior  Specification  activity,  you  make  a  first  cut  at  identifying  and  defining  the 
elements  of  the  behavioral  model  for  the  software  you  are  developing.  You  will  use  the  environmental 
quantities  and  relations  you  identified  in  the  previous  activity  (Identify  Environmental  Variables)  as 
well  as  information  about  sequencing  behavior  (e.g.,  system  modes  or  states)  from  the  tystems 
spedfication  to  perform  the  following  activities: 

•  Identify  and  define  monitored  and  controlled  variables 

•  Identify  domain  and  scheduling  type  for  eadi  controlled  variable 

•  Identify  terms 

•  Identify  the  modes 

The  products  of  this  activity  include  d^nitions  of  the  monitored  and  controlled  variables,  an  overview 
of  each  controlled  variable  domain  and  scheduling  type,  a  description  of  each  term,  and  a  desaiption 
of  eadi  of  the  tystem  mode  machines. 

This  activity  lays  the  foundation  for  subsequent  packaging  and  detailed  specification  activities.  It  is 
intended  to  develop  sufficient  information  about  the  behavioral  requirements  so  thatyou  can  proceed 
to  make  sensible  packaging  decisions.  It  also  lays  the  groundwork  for  the  detailed  spedfication  of  the 
REQ  relation  (the  goal  of  Detailed  Behavior  Specification). 

8.1  GOALS 

The  goals  of  this  activity  are  to: 

•  Identify  whidi  environmental  quantities  you  treat  as  monitored  and  controlled  and  denote 
these  as  monitored  and  controlled  variables. 

•  Determine  whether  the  scheduling  type  for  eadi  controlled  variable  is  periodic  or  demand. 
Identify  M^di  modes  and  monitored  variables  determine  the  controlled  variable’s  value. 

•  Identify  vdiich  terms  are  needed  to  define  the  controlled  variable  functions  and  the  modes. 

•  Determine  how  many  mode  machines  are  needed  and,  for  each,  the  initial  mode  and  the 
allowed  mode  transitions. 
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8.2  ENTRANCE  CRITERIA 

lb  perform  the  Preliminary  Behavior  Specification  activity,  you  need  the  following  products: 

•  The  information  model  developed  in  the  Identify  Environmental  Variables  activity 

•  List  of  likely  changes 

•  System  requirements  or  other  spedfications  defining  system  modes  and  the  sequencing  of 
activities  controlled  by  the  softvme 

83  ACTIVITIES 

The  Preliminary  Behavior  Specification  activify  is  composed  of  the  following  subactivities: 

«  Identy^  and  Define  Monitored  and  Controlled  Varuddes.  Identify  which  quantities  the  software 
will  monitor  and  control  and  denote  them  as  monitored  and  controlled  variables,  respectively. 
Develop  the  definition  of  each  variable,  and  oreate  the  system  context  diagram. 

•  EstaMish  Controlled  HaiaNe  Function  Donutins.  The  REQ  relation  for  each  controlled  variable 
must  be  written  in  terms  of  the  values  or  state  history  of  the  monitored  variables.  In  this  activ¬ 
ity,  you  decide  which  monitored  variables  and  which  modes  determine  the  value  of  each  con¬ 
trolled  variable  and  record  the  information.  You  also  determine  whether  the  controlled 
variable  must  be  set  periodically  or  on  demand. 

•  Define  Mode  Machines.  Determine  the  number  and  characteristics  of  the  mode  machines. 
Decide  how  many  mode  machines  are  needed.  Fbr  eadi  mode  machine,  spedfy  the  modes, 
initial  mode,  and  allowed  mode  transitions.  Identify  and  record  where  one  mode  machine  de¬ 
pends  on  another.  Identify  and  record  which  controlled  variables  depend  on  which  mode 
machines. 

83.1  lDQ«niFY  AND  DeXINE  MONITORED  AND  CONTROLLED  VARIABLES 

The  goal  of  this  activity  is  to  define  the  monitored  and  controlled  variables  you  use  to  write  the  REQ 
and  NAT  relations,  lb  start  this  activify,  you  need  the  set  of  attributes,  attribute  definitions,  and  ap¬ 
plication-specific  relations  you  identified  in  the  Identify  Environmental  Variables  activify.  The  prod¬ 
ucts  of  this  activify  are  the  system  context  diagram  and  the  definition  of  each  monitored  and  controlled 
variable  in  your  spedfication. 

Start  Ify  identifying  the  controlled  variables.  Because  the  ultimate  purpose  of  the  monitored  variables 
is  to  allow  you  to  write  the  controlled  variable  functions,  exactly  which  monitored  variables  are  most 
approj^-iate  depends  on  the  dioice  of  controlled  variables. 

83.1.1  Identify  Controlled  Variables 

In  this  activify,  you  identify  which  environmental  quantities  you  denote  as  controlled  variables  and 
create  the  corresponding  controlled  variable  definitions.  Tb  identify  the  controlled  quantities,  first  ex¬ 
amine  the  attributes  and  application-spedfic  relations  created  in  the  Identify  Environmental  Vari¬ 
ables  activity.  Examine  the  attribute  definitions  and  the  relations  to  determine  which  quantities  are 
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partially  or  completely  under  control  of  the  software.  Look  for  devices  whose  states  are  set  by 
software,  situations  where  information  is  supplied  to  the  operator  or  to  other  systems,  and  situations 
where  other  quantities  are  produced  or  affected  by  the  software.  If  you  have  previously  determined 
whidi  quantities  are  controlled  and  have  produced  an  attribute  matrix  relating  attributes,  use  that 
information  to  identify  controlled  quantities.  You  may  also  use  information  from  systems  engineering 
specifications  about  the  visible  behavior  of  the  system  to  determine  which  quantities  should  be  treated 
as  controlled. 


ExMtTLE:  You  determine  from  the  information  model  for  the  FLMS  (Figure  7-1)  and  the 
attribute  matrix  (Ihble  7-S)  that  the  following  attributes  can  be  denoted  as  controlled  variables: 

•  Audible  Alarm 

•  Low  Alarm 

•  High  Alarm 

•  Fuel  Level  Display 

•  ShutdownRelay 

The  relations  in  the  model  indicate  that  the  system  must  provide  the  operator  with  information 
represented  by  the  first  four  attributes.  The  softv^e  controls  the  state  of  the  ShutdownRelay  to  carry 
out  its  primary  duty  as  a  safety-shutdown  system.  The  software  also  has  partial  control  over  the  fuel 
flow  because  the  state  of  the  relay  affects  the  pum|». 

In  most  cases,  you  will  be  able  to  develop  the  clearest  and  simplest  spedfication  if  you  treat  the  device 
state  as  controlled  instead  of  the  environmental  quantities  affected  by  the  devices.  For  example,  you 
would  treat  the  FLMS  ShutdownRelay  as  controlled  rather  than  the  fuel  flow.  This  is  because  the 
states  of  the  environmental  quantities  are  often  affected  by  factors  outside  the  control  of  the  software, 
making  the  relation  between  monitored  and  controlled  complicated  and  indirect.  In  contrast,  the 
^tern’s  devices  are  typically  directly  tmder  software  control. 

8  J.1,2  Identify  Monitored  Variables 

In  this  activity,  you  identify  which  environmental  quantities  you  denote  as  monitored  variables  and 
create  the  corresponding  monitored  variable  definitions. 

Identifying  the  monitored  variables  is  inherently  an  activity  that  must  be  revisited  during  several  of 
the  CoRE  spedfication  activities.  The  choice  of  which  quantities  to  treat  as  monitored  is  ultimately 
driven  by  what  information  you  will  need  to  write  the  controlled  variable  functions  and  to  track  mode 
changes.  While  you  should  make  a  preliminary  identification  of  the  monitored  quantities  as  you 
identify  the  controlled  variables,  you  will  revisit  the  activity  as  follows: 

•  As  you  determine  which  monitored  quantities  each  controlled  variable  value  depends  on 
during  the  Identify  Environmental  Variables  activity 

•  As  you  determine  which  monitored  quantities  are  needed  to  define  the  mode  transitions  in 
the  Detailed  Behavior  Spedfication  activity 
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•  As  you  oomfriete  the  specifications  of  the  controlled  variable  functions  and  terms  in  the 
Detailed  Behavior  Specification  activity 

Rather  than  repeat  the  guidance  for  identifying  and  specifying  the  monitored  variables  in  each  of  these 
activities,  this  section  gives  an  overview  of  the  steps  and  products. 

The  goal  during  Preliminary  Behavior  Spedfication  is  to  identify  all  the  monitored  variables  needed 
to  complete  the  Establish  Controlled  triable  Rmction  Domains  activity.  When  you  complete  the 
Preliminary  Behavior  Spedfication  activity,  you  should  have  a  definition  for  each  monitored  variable 
you  identified  as  needed  for  the  controlled  variable  function  domains. 

Examples  In  Figure  7-1,  the  fdlowing  pc^ntial  envircmmental  variables  can  be  monitored  variaUes: 

•  Setftest  Switch 

•  Reset  Switch 

•  Power 

•  Fuel  Level 

•  Fuel  Flow  Rate 

The  operator  can  set  the  first  two  switches.  Power  indicates  whether  the  ^tem  has  electrical  power. 
Fuel  Level  represents  the  level  of  fuel  in  the  tank,  and  Fuel  Flow  Rate  is  a  measure  of  the  rate  of  flow 
of  fuel  into  or  out  of  the  tank. 

You  will  dioose  the  monitored  quantities  based  on  the  information  you  need  to  write  the  controlled 
variable  functions,  identify  undesired  events,  and  track  state  changes  as  follows: 

•  Controlled  HaiaUe  Function  Domains.  After  you  have  identified  the  set  of  controlled  variables,  you 
mtist  dedde  \^cfa  quantities  you  will  use  to  determine  the  required  values  of  the  controlled  vari¬ 
ables.  As  a  first  step,  look  at  the  attributes  you  identified  in  the  Identify  Environmental  Variables 
activity.  An  attribute  that  can  be  used  to  determine  the  required  value  of  a  controlled  variable  may 
be  modeled  as  a  monitored  variable.  Use  the  application-spedfic  relations  (e.g.,  from  the  attrib¬ 
ute  matrix,  ERD,  or  other  material  defining  your  information  model)  to  identify  attributes  related 
to  eadi  controlled  variable.  Remembo’  that  a  variable  can  be  both  monitored  and  controlled. 

•  Undeared  Events.  The  inabilify  of  the  software  to  determine  the  value  of  a  monitored  quantity 
or  set  the  value  of  a  controlled  one  is  modeled  as  an  undesired  event.  This  includes  the  inabilify 
to  monitor  the  value  to  the  required  predsion  or  set  a  controlled  value  within  the  required 
tolerance.  You  create  a  monitored  variable  that  models  the  undesired  state  and  abstracts  from 
the  set  of  possible  failures  (e.g.,  the  particulars  of  device  failures,  etc.). 

ExampleSs  The  FLMS  system  requirements  tell  us  that,  if  the  FLMS  system  cannot  determine 
the  current  fiiel  level  (Le.,  the  value  of  mon_Fiiel_Level),  the  software  must  detect  the  failure  and 
take  the  fail-safe  approadi  of  shutting  down  die  pumps.  You  can  deimte  this  undesired  event  by 
modeling  the  inabilify  to  determine  with  a  monitored  variable,  mon_Fuel_Level_Unknown,  de¬ 
noting  viiether  the  system  is  able  to  determine  the  value  of  mon_Fuel_Levei  to  the  desired  accu¬ 
racy.  Thus,  you  define  two  monitored  quantities  relating  to  the  fuel  level:  mon_Fuel_Level, 
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denoting  the  level  of  fuel  in  the  tank,  and  mon_Fuel_Level_Unknown,  denoting  the  ^tern’s 
inability  to  determine  that  value. 

Consider  an  operational  flight  program  for  an  aircraft  that  must  provide  the  altitude  of  the 
aircraft  in  a  pilot  display.  The  required  accurate  depends  on  factors  like  the  current  altitude 
and  which  devices  are  factional.  Create  a  monitored  variable,  mon_Altitude_Accuracy,  to 
denote  the  accuracy  with  which  the  software  can  determine  the  value  of  the  monitored  variable 
mon_Altitude,  and  use  it  to  specify  the  required  accuracy  of  the  altitude  display. 

•  Mode  Determination.  As  you  identify  and  define  the  modes,  you  will  define  the  events,  causing 
mode  transitions  in  terms  of  changes  in  the  monitored  variables.  You  may  add  monitored 
variables  based  on  the  need  to  track  state  changes. 

You  will  often  have  a  choice  among  quantities  you  can  treat  as  monitored.  For  example,  in  the  FLMS, 
you  might  choose  to  denote  as  a  monitored  variable  the  fuel  level  in  the  tank,  the  fuel  pressure,  the 
fuel  volume,  or  even  the  fuel  flow  into  and  out  of  the  tank  to  determine  whether  there  is  too  much  or 
too  little  fuel  in  the  tank.  You  must  choose  a  quantity  that  is  feasible  to  measure  given  the  overall  sys¬ 
tem  specification,  your  understanding  of  the  hardware,  and  physical  constraints.  You  then  choose  the 
monitored  quantity  based  on  the  audience  for  the  specification  and  how  easily  you  can  express  the 
required  behavior  in  terms  of  that  quantity.  The  specification  conununicates  best  to  its  audience  if  you 
choose  quantities  that  mirror  your  audience’s  understanding  of  the  problem  (e.g.,  choose  a  quantity 
that  the  customer  understands).  For  ease  of  use,  choose  the  quantities  that  most  directly  m^el  the 
information  you  need  to  express  the  controlled  variable  behavior  (i.e.,  those  that  result  in  the  simplest 
functions). 

As  you  develop  the  CoRE  specification,  you  should  remove  redundant  and  unnecessary  monitored 
variables: 

•  If  two  variables  denote  the  same  quantity  or  if  you  can  derive  the  value  of  one  monitored 
variable  from  another,  the  variables  are  redundant.  Where  one  quantity  can  be  determined 
from  another,  you  should  consider  creating  a  term  to  denote  the  derived  quantity.  In  general, 
it  will  be  easier  to  manage  change  (e.g.,  if  the  purpose  for  the  monitored  variable  changes  or 
goes  away)  if  you  remove  such  redundancies.  For  example,  the  quantities  Fuel  Flow  Rate  and 
Fuel  Level  are  redundant  for  the  purposes  of  the  FLMS  because  one  can  be  calculated  from 
the  other. 

•  A  monitored  quantify  is  unnecessary  if  it  is  never  used  to  determine  the  value  of  a  controlled 
variable  or  to  determine  a  mode  or,  equivalently,  used  in  a  term  that  serves  one  of  these 
purposes.  Before  you  complete  the  specification,  you  should  remove  any  unused  variables. 

83.13  Define  Monitored  and  Controlled  Variables 

In  this  activity,  you  record  definitions  of  variables  to  communicate  your  decisions  precisely  to  other 
engineers.  If  you  have  already  created  parts  of  these  definitions  in  the  Identify  Environmental 
Wniables  activity,  you  review  and  refine  those  decisions  in  this  activify. 

In  creating  a  monitored  or  controlled  variable,  you  are  abstracting  from  the  (usually  physical)  quantify 
in  the  environment  you  must  monitor  or  control.  The  variable  represents  the  essential  information 
about  the  quantify  for  which  you  need  to  write  the  requirements  while  abstracting  from  incidental 
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details.  For  ocample,  you  give  a  monitored  variable  only  the  predsion  required  to  set  the  controlled 
variables  to  sufficient  accuracy  although  the  actual  quantity  has  no  limit  on  its  precision. 

Name  and  lype.  Choose  names  that  are  commonly  used  to  denote  the  environmental  quantity. 
Choose  the  type  based  on  how  the  variable  will  be  used;  i.e.,  dioose  units  that  are  convenient  to 
represent,  ea^  to  use  to  egress  the  required  values,  and  understandable  to  the  document’s  users. 

>Uacs.  Use  the  NAT  relation  to  determine  the  range  of  values  a  given  quanti^  can  assume  (e.g., 
mmrimum  and  minimum  fuel  levels  are  determined  1^  the  configuration  of  the  tank).  Define  the  pos¬ 
sible  values  of  the  variable  within  this  range.  For  enumerated  variables,  list  the  values  (see  Ihble  ^1). 
For  numeric  variables,  record  the  lowest  and  highest  values  the  variable  can  assume  (see  Ihble  8-2). 
The  range  of  values  defines  the  range  over  which  the  software  must  be  able  to  represent  the  monitored 
or  controlled  variable;  thus,  you  should  define  only  the  range  that  is  actually  needed.  For  example, 
if  very  large  values  of  altitude  for  a  particular  aircraft  are  never  needed,  do  not  indude  these  values 
in  the  range. 


IhUe  8-1.  Definition  of  Enumerated  Environmental  Variable 


Name  'type 

Values 

Physical  Interpretation 

oonjSliutdowa_ReIay  ENUMERATED 

dosed 

The  fuel  pump  shutdown  relay  is  dosed,  and 

the  fuel  pump  is  enabled. 

open 

The  fuel  pump  shutdown  relay  is  open,  and 

the  fuel  pump  is  disabled. 

Ikble  8-2.  Definition  of  Numeric  Environmental  Variable 


Name  'Qrpe  Values  Predsion  Physical  Interpretation 

mon_Fhel_Level  LENGTH  0.0.30.0  03  Level  of  fuel  in  the  tank,  in  centimeters  (cm), 

alongthe  vertical  axis  on  the  left  side  of  the  tank, 
5  cm  from  the  front  edge.  The  level  is  measured 
with  respect  to  the  scale. 


Predsion.  For  a  monitored  variable,  use  the  predsion  to  opress  how  accurately  the  software  is 
required  to  measure  the  actual  quantity  that  the  monitored  variable  represents.  Predsion  may  be  im- 
plidt  in  the  range  of  values  or  it  may  be  explidtly  indicated  (as  in  Ihble  8-2).  If  predsion  were  not  ex- 
plidt  in  Ihble  8-2,  the  zeroes  following  the  dedmal  points  in  the  values  spedfication  of 
mon_Fiiel_Level  would  indicate  that  it  has  a  predsion  of  0.1  cm  (rather  than  0.5  cm,  which  is  indicated 
by  Predsion  in  the  table).  The  0.5  cm  predsion  expresses  the  requirement  that,  using  the  available 
input  resources  over  time,  the  software  must  be  able  to  determine  the  actual  fuel  level  to  plus  or  minus 
0.5  cm.  You  use  the  predsion  to  help  determine  the  adequacy  of  the  inputs. 

For  a  controlled  variable,  use  the  predsion  to  express  how  accurately  the  software  must  be  able  to  set 
die  actual  quantity  that  the  controlled  variable  represents.  For  otample,  if  the  controlled  variable  rep¬ 
resents  the  angle  on  a  flap  and  the  predsion  is  03  degree,  this  oipresses  the  requirement  that  the  soft¬ 
ware  be  able  to  set  the  angle  to  within  03  degree.  Use  the  predsion  of  a  controlled  variable  to  help 
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determine  if  you  can  satisfy  the  required  tolerances  on  the  controlled  variable  functions  based  on  the 
available  output  devices. 

Physical  Interpretation.  Use  the  physical  interpretation  to  describe  the  relationship  between  the 
monitored  or  controlled  variable  and  the  quantity  that  the  variable  denotes.  The  physical  interpreta¬ 
tion  allows  you  to  relate  the  quantities  used  to  write  the  specification  to  externally  visible  phenomena. 
This  allows  the  specification’s  readers  (e.g.,  customers,  system  engineers,  testers)  to  correlate  the  re¬ 
quirements  described  in  the  specification  to  the  ot^ervable  behavior  of  the  software.  Thus,  the  Phjrsi- 
^  Interpretation  should  be  defined  so  it  is  clear  to  the  specification’s  readers  exactly  what  quantity 
the  variable  denotes. 

Fbr  enumerated  variables,  describe  the  physical  interpretation  of  each  possible  value  of  the  variable 
(see  Tkble  8-1).  Where  the  variable  m^els  relative  quantities  (e.g.,  coordinate  systems,  angle  of 
attadc,  separation),  use  figures  to  give  the  predse  meaning  of  the  quanti^  being  modeled. 

83.1.4  Create  the  System  Context  Diagram 

After  you  have  identified  the  monitored  and  controlled  variables,  you  can  create  the  system  context 
diagram.  An  initial  version  of  the  diagram  can  be  used  as  a  visual  guide  to  your  spedfication’s  moni¬ 
tor^  and  controlled  quantities  and  is  used  in  constructing  and  assessing  the  level-0  dependency  graph. 
The  final  context  diagram  that  reflects  your  ultimate  choices  of  monitored  and  controlled  variables 
is  induded  in  the  final  CoRE  specification. 

You  CTcate  the  context  diagram  for  your  software  following  instructions  in  Seaion  5.3.1.  A  context 
diagram  for  the  ELMS  is  shown  in  Appendix  B,  Figure  B.l. 

83.2  Estabush  Controlled  Variable  Function  Domains 

The  goal  of  this  activity  is  to  identify  information  you  need  to  define  the  requirements  for  eac*  controlled 
vari2d)le.  In  particular,  you  identify  the  domain  of  the  controlled  variable  function  by  identifying  the  set 
of  mcxles  and  the  information  about  the  monitored  variables  that  determine  the  controlled  variable’s  val¬ 
ue.  You  also  identify  Miether  the  scheduling  requirement  for  settmg  the  controlled  variable  is  pericxiic 
or  demand 

lb  perform  this  activity,  you  need  the  definitions  you  created  in  the  Identify  and  Define  Monitored 
and  Controlled  Variables  activity.  You  need  the  application-specific  relations  from  the  Identify  Envi¬ 
ronmental  Variables  activity.  You  also  need  the  systems  specification  or  other  documentation  defining 
the  originating  requirements.  The  product  of  this  activity  is  a  controlled  variable  overview  (e.g.,  like 
in  Figure  8-1).  You  use  the  products  of  this  activity  to  refine  your  decisions  about  which  monitored 
variables  and  terms  are  needed  and  to  make  initial  decisions  about  the  number  of  mode  machines 
needed  and  the  modes  of  each  (in  the  Define  Mode  Machines  activity).  You  also  use  this  information 
in  Class  Structuring  to  make  packaging  decisions.  You  refine  the  products  of  this  activity  to  develop 
a  complete  specification  of  the  controlled  variables  functions  and  timing  constraints  in  Detailed 
Behavior  Specification. 

For  each  controlled  variable,  begin  by  looking  at  its  definition.  For  this  activity,  the  goal  is  to  identify 
the  monitored  variables,  information  about  monitored  variables,  or  modes  that  affect  the  required 
value  of  the  controlled  variable.  The  product  of  this  activity  is  a  summary  of  the  information  needed 
to  specify  each  controlled  variable  captured  in  a  form  like  the  Controlled  Variable  Overview  form  in 
Figure  8-1. 
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Controlled  VbrinUe  Name:  oon_Low_Alarm 
Monitored  V^maUes: 

mQn_Riel_Level  Set  idien  fuel  level  falls  below 

lower  safety  level  thresbdd 

moii_Fuel_Level_FEul  Set  vdxoi  cannot  detennine  level 

nx>n_Selflest_Switdi  On  during  self-test 

Modes: 

mode_Test  \Uue  is  a  fiinctioo  of  time  in 

test 

niode_OpeFating  \Uue  is  a  function  of  fuel  level 

mode_BadLevDev  Wue  is  a  functioned  mode 

Scheduling  Requirements:  demand 

Traceability: 

(2)  Whenthe]evelinthetankexceedstheupperorlowerlimits,analarmistTiggered. 

(5)  If  the  system  is  unable  to  determine  the  fuel  level  of  the  tank,  the  system  shall 
notify  the  operato'  of  the  conditkm  aiKi  shut  down  the  pump. 

(6)  A  capability  to  ocnduct  system  self-testing  shall  be  provided. 

(12)  The  system  shall  dis{day  fuel  level  and  status  alarms  to  the  (^aerator. 

(13)  Indications  <d  low  or  high  fuel  levels  (hazardous  conditions)  or  unknown  fuel 
levels  shall  be  presented  to  the  operator. 

(14)  Wheneverthereisahazardousconditionoranunknown,the^em  shall  provide 
audible  and  visual  alarms. 


Rgure  8-1.  Controlled  \^riab!e  Overview  for  con_Low_Alarm 


83,2.1  Identify  Monitored  Variables 

In  this  activity,  you  identify  the  set  of  monitored  variables  and  the  information  about  those  variables 
that  determine  the  value  of  the  controlled  variable.  You  use  this  information  in  Class  Structuring  to 
identify  the  monitored  variables  and  terms  that  must  be  defined  in  the  class  interfaces. 

Look  at  the  set  of  application-specific  relations  from  the  Identify  Environmental  Variables  activity 
that  connect  the  controlled  variable  to  other  attributes.  Those  attributes  that  are  modeled  as  moni¬ 
tored  variables  are  prime  candidates.  Where  you  identify  a  monitored  variable  as  affecting  the  value 
of  a  controlled  variable,  record  vdiat  information  about  the  variable  is  needed.  You  should  find  this 
in  the  originating  requirements  for  the  affected  controlled  or  monitored  quantities.  If  the  controlled 
variable  is  a  function  of  several  monitored  quantities  or  otherwise  requires  a  more  complex  expression 
to  capture,  you  may  ch(x>se  to  create  some  im'tial  terms  to  capture  ^e  information  needed.  Add  the 
originating  requirements  or  traceability  to  the  controlled  variable  overview. 
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You  must  also  consider  how  the  required  behavior  changes  as  the  s;^tem  state  changes,  lb  do  this,  you 
need  to  iterate  between  this  activity  and  identifying  the  system  modes.  Look  for  states  where  the  set 
of  relevant  monitored  variables  changes.  Also  look  for  failure  states  where  your  ability  to  set  the 
controlled  variable  is  affected  by  undesired  events.  Where  these  undesired  events  are  modeled  as 
monitored  variables,  they  must  be  included  in  the  domain. 

You  iterate  between  this  activity  and  identifying  the  monitored  variables  as  you  identify  places  where 
additional  or  different  information  is  needed  to  develop  the  controlled  variable  functions. 

£x4mple:  If  you  look  at  the  stated  requirements  for  the  FLMS  controlled  variable 
con_Low_Alarm,  you  see  that  the  alarm  is  signaled  when  the  fuel  level  is  too  low;  therefore,  it  de¬ 
pends  on  the  value  of  the  monitored  variable  mon_Fuel_Level.  The  specific  information  you  need 
about  the  fuel  level  is  whether  the  current  level  is  below  the  minimum  safe  level.  In  examining  the 
attribute  matrix,  you  also  determine  that  the  controlled  variable  value  is  a  function  of  the  FLMS 
attribute  Failure,  which  is  modeled  with  the  monitored  variable  mon_Fuel_Level_Fail. 

S3JZJZ  Identify  Modes 

In  this  activity,  you  identify  a  set  of  modes  that  determine  the  value  of  the  controlled  variable.  Tb 
identify  modes,  you  must  look  at  the  controlled  variable’s  definition  and  any  information  about  se¬ 
quencing  or  state  behavior  that  affects  the  variable.  For  example,  you  must  examine  the  system  specifi¬ 
cation  to  determine  if  the  behavior  depends  on  sequences  of  actions  by  the  user;  whether  the  system 
is  in  an  initiation,  operation,  or  maintenance  mode;  and  so  on.  In  general,  you  are  looking  for  points 
at  which  changes  in  values  of  the  monitored  variables  result  in  changes  in  the  controlled  variable  func¬ 
tion  (i.e.,  points  of  discontinuity).  You  represent  each  such  distinct  state  with  a  name  and  brief 
desaiption  of  the  behavior  that  distinguishes  the  state. 

You  iterate  between  this  activity  and  the  Define  Mode  Machines  activity  (Section  8.3.3).  Where 
system  mode  machines  have  already  been  defined,  you  can  express  this  partitioning  of  system  state 
in  terms  of  the  mode  names.  Otherwise,  you  use  this  information  to  derive  the  necessary  modes  and 
mode  machines. 

Example:  The  controlled  variable  function  for  con_Low_Alarm  exhibits  different  behavior  in 
different  states  of  the  system.  During  normal  operations,  the  alarm  value  is  a  function  of  the  fuel 
level.  During  a  system  self-test,  however,  the  value  is  a  function  of  the  time  since  the  self-test  was 
initiated.  The  alarm  is  also  used  to  indicate  failure  of  the  level-measuring  device;  here,  it  is  a 
function  of  the  state  of  the  device. 

In  this  example,  the  function  is  divided  into  three  parts,  depending  on  whether  the  system  is  in  a 
normal  operating  state  or  undergoing  self-test  or  whether  a  device  has  failed.  These  states  or  oper¬ 
ating  modes  partition  the  domain  of  the  controlled  variable  function  because  the  system  can  be 
in  only  one  of  these  states  at  a  time. 

8333  Identify  Scheduling  Requirements 

You  use  the  scheduling  requirements  to  specify  when  the  controlled  variable  value  must  be  set. 
Scheduling  requirements  are  classified  as  periodic  or  demand:  A  scheduling  requirement  is  periodic 
only  if  the  controlled  variable  is  required  to  be  set  at  certain  intervals.  For  example,  a  value  must  be 
supplied  as  part  of  a  feedback  control  loop  every  200  milliseconds.  Classify  the  controlled  variable  as 
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demand  if  the  setting  of  the  controlled  variable  is  triggered  by  the  change  in  value  of  some  monitored 
quantity  or  mode. 

Neither  input  nor  output  hardware  characteristics  determine  whether  a  controlled  variable  is 
periodic.  For  example,  the  fact  that  the  monitor  used  to  display  the  controlled  variable  con_Fuel_Lev- 
el  is  updated  at  a  certain  frequency  does  not  make  its  REQ  relation  periodic.  The  requirement  is  that 
the  value  be  provided  to  a  certain  accuracy  and  within  a  certain  minimum  delay.  The  designer  must 
work  within  the  constraints  of  the  refresh  rate  to  ensure  that  these  requirements  are  satisfied.  The 
periodic  constraint  in  this  case  belongs  to  the  OUT  relation,  not  REQ. 

8JJ  Define  Mode  Machines 

The  goal  of  this  activity  is  to  identify  the  mode  machines  needed  to  write  the  behavior  specification, 
lb  perform  this  activity,  you  need  the  controlled  variable  overviews,  particularly  the  modes  you  identi¬ 
fied  in  the  Establish  Controlled  Variable  Function  Domains  activity.  You  also  need  any  available  in¬ 
formation  from  systems  specification  and  related  documents  on  the  system  modes  and  other 
requirements  based  on  system  state  or  sequencing  between  activities. 

The  product  of  this  activity  is  an  initial  mode  machine  specification  specifying  each  distinct  mode 
machine  needed,  the  set  of  modes  in  each  machine,  the  set  of  possible  mode  transitions,  and  the  im'tial 
mode  for  each  machine.  You  use  this  information  in  the  Class  Structuring  activity  to  identify  classes 
to  encapsulate  the  mode  machines.  You  also  use  the  information  in  the  Detailed  Behavior 
Specification  activity  to  complete  the  definitions  of  the  controlled  variable  functions  and  to  complete 
the  detailed  spedfications  of  the  mode  machines. 

In  a  Core  spedfication,  mode  machines  are  typically  used  to  capture  state  information  that  is  used 
to  spedfy  a  number  of  controlled  variable  functions.  This  means  that,  in  developing  the  modes,  you 
need  to  consider  the  software  states  in  the  large  (i.e.,  behavior  during  system  initialization,  test,  main¬ 
tenance,  etc.)  and  that  you  will  need  to  consider  the  effects  of  these  state  and  state  transitions  across 
a  number  of  controlled  variables.  In  particular,  you  use  a  mode  machine  where: 

•  The  externally  visible  behavior  (i.e.,  the  values  of  one  or  more  controlled  variables)  differs 
from  one  mode  to  the  next. 

•  The  system  dianges  behavior  when  changes  in  the  values  of  monitored  quantities  (events)  occur. 

You  typically  iterate  between  defining  the  mode  machines  and  identifying  the  controlled  variable 
function  domains,  beginning  with  a  sketch  of  possible  mode  machines  and  refining  that  sketch  as  the 
requirements  are  better  understood.  You  may  not  completely  identify  the  modes  until  you  have 
completed  much  of  the  Detailed  Behavior  Specification  aaivity. 

S33.1  Identify  Mode  Machines 

Each  machine  determines  the  state  for  a  distinct  set  of  the  controlled  variable  functions.  Use  the  mode 
information  from  the  controlled  variable  functions  and  your  understanding  of  the  distinct  types  of  acti¬ 
vities  in  the  system  to  identify  the  different  mode  madiines.  The  modes  of  a  mode  machine  are  related 
by  a  common  set  of  concerns.  The  following  discussion  provides  some  heuristics  for  finding 
appropriate  mode  machines. 
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Exmiple:  An  aircraft’s  navigation  system  must  periodically  update  the  aircraft’s  current 
position,  i.e.,  provide  a  new  (presumably  more  accurate)  latitude  and  longitude.  There  are  several 
ways  of  updating  a  position;  the  system  chooses  the  appropriate  method  depending  on  the  pilot’s 
actions  and  the  state  of  the  aircraft.  Each  of  these  possibilities  corresponds  to  a  navigation  update 
mode;  collectively,  they  form  the  Navigation  Update  mode  machine.  Modes  of  the  machine  are 
related  in  that  the  system  performs  the  same  basic  service  (updating  position)  in  each.  They  differ 
in  the  method  of  acquiring  the  new  position.  Similarly,  a  Weapons_Derivery  mode  machine  would 
be  concerned  with  delivering  the  different  weapons  that  the  aircraft  can  carry.  Each  mode  of  the 
machine  corresponds  to  the  delivery  of  a  weapon  or  set  of  weapons  with  somewhat  different 
characteristics. 

While  there  is  no  hard  and  fast  procedure  for  deciding  which  mode  machines  are  needed,  the  following 
are  common  in  embedded  systems: 

•  Represent  Distinct  System  Functions.  Most  systems  have  a  varied  of  states  in  addition  to  their 
normal  operation.  These  include  states  in  which  the  system  performs  self-test,  undergoes 
maintenance,  or  operates  under  a  variety  of  failure  or  degraded  conditions.  Modeling  such 
mutually  exclusive  system  functions  as  modes  allows  you  to  simplify  the  REQ  relations. 

Example:  The  self-test  and  failure  states  of  the  FLMS  are  examples. 

•  Embody  a  Sequence  of  Activities.  The  system  is  the  primary  agent  or  one  partner  (e.g.,  in 
cooperation  with  a  person)  in  carrying  out  a  sequence  of  activities  directed  toward  some  goal. 
The  value  of  the  controlled  variable  depends  on  where  you  are  in  the  sequence.  Model  the 
steps  of  the  sequence  as  the  modes  of  a  mode  machine. 

Example:  The  FLMS  is  the  primary  agent  in  carrying  out  the  safety  shutdown  sequence  for 
the  shipboard  fuel  system.  Roughly,  the  sequence  is  to  monitor  the  fuel  level  for  safety.  When 
an  unsafe  level  is  detected,  sound  the  alarm  and  briefly  wait  to  see  if  the  fuel  returns  to  a  safe 
level.  If  the  fuel  returns  to  a  safe  level,  return  to  monitoring;  otherwise,  shut  down  the  system. 
The  distinct  steps  of  this  activity  are  modeled  with  mode_Operating,  mode_Hazard,  and 
mode_Shutdown.  The  behaviors  of  most  of  the  controlled  variables,  including 
con_AudibIe_Alarm,  are  defined  as  the  modes  of  the  shutdown  procedure. 

•  Model  System  Modes.  The  system  specification  may  allocate  certain  modes  to  the  software  or 
give  the  software  responsibility  for  maintaining  modes  visible  to  the  system’s  user.  For  exam¬ 
ple,  it  is  conunon  to  organize  the  pilot’s  view  of  an  avionics  system  into  different  modes  of  op¬ 
eration,  such  as  the  navigation  modes  or  weapon  modes.  There  will  be  a  navigation  mode 
machine  and  a  weapon  mode  machine.  In  such  cases,  it  often  makes  sense  to  organize  the  re¬ 
quirements  according  to  these  modes.  Such  an  organization  is  consistent  with  the  customer’s 
view  and  simplifies  the  presentation. 

8  J3.2  Identify  Modes  and  Transitions 

For  each  mode  machine  you  have  identified,  you  must  determine  the  machine’s  modes,  the  set  of 
possible  transitions,  and  the  initial  mode. 

You  choose  the  set  of  modes  based  on  your  understanding  about  the  states  of  the  system  of  interest 
and  the  information  you  derived  from  defim'ng  the  REQ  relation  domains  in  the  previous  activity.  You 
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need  to  create  a  mode  for  each  distinct  set  of  required  behaviors  (i.e.,  as  distinguished  by  points  of 
discontinuity  in  state-related  behavior). 

Create  a  name  for  the  mode  that  corresponds  to  an  external  view  of  the  state  and  concatenate  with 
inodejclass_.  Fbr  example,  for  an  avionics  system,  you  would  choose  mode  names  that  correspond 
to  the  pilot’s  view  of  the  operating  modes  of  the  aircraft.  Thus,  the  mode_class_Attack  might  include 
mode_Air_to_Alr  for  air-to-air  combat  and  mode_^r_to_Ground  for  an  air-to-ground  mission. 

Select  the  initial  mode  by  determining  which  operations  must  be  performed  on  system  initialization. 
You  may  aeate  an  initialization  mode  to  capture  the  unique  required  behavior  during  system 
initialization. 

Use  the  information  you  derived  from  defining  the  REQ  relation  domains  and  any  sequencing 
information  from  the  system  specification  to  identify  the  transitions. 

The  set  of  modes  in  a  mode  machine  must  be  defined  so  that  the  system  is  always  in  exactly  one  mode 
of  the  class.  In  this  way,  you  ensure  that  the  mode  machine  covers  the  domain  of  the  REQ  functions 
(i.e.,  every  partition  corresponds  to  at  least  one  mode  of  the  machine).  You  must  also  make  sure  that 
there  is  at  least  one  path  to  every  mode  and  there  is  at  least  one  path  out  of  every  mode  unless  the 
mode  is  a  terminal  state  of  the  system. 

Example:  In  the  example  for  con_Low_A!arm  in  Section  8.3.1,  you  identified  three  states 
affecting  the  REQ  relation.  Further  analysis  shows  that  the  oAer  alarms  in  the  FLMS 
(con_High_Alarm  and  con_Audible_Alarm)  also  depend  on  the  same  states,  i.e.,  whether  the  sys¬ 
tem  is  operating  normally,  the  level  detection  device  has  failed,  or  the  intern  is  in  self-test. 
cause  the  ^tem  can  only  be  in  one  of  the  operating  modes,  the  test  mode,  or  the  failure  mode 
at  a  given  time,  you  can  model  all  of  these  states  as  the  modes  mode_Operating, 
mode^BadLevDev,  and  modeJTest  of  a  sin^e  mode  machine. 

In  addition,  there  are  distinct  states  that  the  system  must  track  during  the  safety  shutdown  procedures. 
These  are  states  you  would  identify  in  writing  the  REQ  relation  for  the  controlled  variable  con_Shut- 
down_Relay  that  is  used  to  turn  the  pumps  off  during  a  system  shutdown.  In  addition  to  the  operating 
state  (mode_Operating)  when  the  &ei  level  is  within  limits,  there  is  a  hazard  notification  state  when 
the  fuel  level  is  out  of  the  safe  range.  When  the  fuel  level  stays  out  of  the  safe  range  for  too  long,  the 
^tem  shuts  down.  These  states  can  be  modeled  as  two  additional  modes,  mode_Hazard  and 
mode_Shutdown.  This  makes  five  modes  needed  to  write  the  REQ  functions  for  the  FLMS 
controlled  variables  see  (Figure  8-2). 

8.4  EVALUATION  CRITERIA 

Evaluate  the  products  of  this  activity  by  answering  the  following  questions: 

•  Is  the  definition  of  eadi  of  the  monitored  and  controlled  variables  complete? 

•  Have  you  identified  the  monitored  variables  and  modes  that  each  controlled  variable  value 
depends  on? 

•  Is  the  set  of  modes  defined  for  each  controlled  variable  domain  consistent  with  the  contents 
of  the  mode  machines? 
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Rgure8-2.  Using  a  Mode  limsitioa  Diagram  to  Represent  iiiode_cIass_In_Operatiot> 

•  1$  eadi  mode  machine  well  formed  according  to  the  criteria  in  Section  4.2.5? 

•  Do  each  of  the  mode  machines  satisfy  the  mode  machine  criteria  that  every  state  is  readiable 
and  that  every  state  has  an  exit  unless  it  is  a  terminal  state? 

8^  EXIT  CRITERIA 

You  have  completed  this  activity  when  you  have  produced  the  following  work  products  and  you  can 
answer  “yes”  to  each  of  the  questions  in  Section  8.4. 

•  Monitored  and  controlled  variable  definitions 

•  The  ^tem  context  diagram 

•  An  overview  for  each  controlled  variable 

•  Initial  mode  machine  definitions 
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In  the  Qass  Structuring  activity,  you  make  and  refine  the  packaging  dedsions  for  the  specification. 
In  Preliminary  Behavior  Specification,  you  determined  the  basic  structure  of  the  behavioral  nnxlel. 
You  defined  the  environmental  variables  and  made  jn-eliminary  dedsions  about  the  behavioral  model, 
indwling  the  controlled  variable  functions,  scheduling  requirements,  modes,  and  terms.  In  Class 
Structuring,  you  deddewhidipartsof  the  behavior  specification  will  be  allocated  to  \riiididasses.  You 
dedde  vdiicfa  parts  of  the  behavior  spedfication  be  encapsulated  by  each  dass  and  vriiidi  will 
appear  on  the  dass  interface  based  on  your  packaging  goals. 

As  part  of  aeating  the  dass  structure,  you  also  make  decisions  about  the  encapsulation  structure  and 
the  generalization/spedalization  structure.  You  determine  whidi  dasses  will  encapsulate  the  defini¬ 
tions  of  other  classes  and  define  those  internal  dass  structures.  You  use  information  about 
commonality  in  the  requirements  to  create  superdasses  and  define  their  subdasses. 

Enalty,  you  determine  how  the  definition  of  each  dass  depends  on  information  defined  in  other 
dasses.  ^operties  like  ease  of  change,  reusability,  readability,  and  the  impact  of  fuzzy  requirements 
are  determined  the  packaging  dedsions  nuule  in  this  activity. 

9.1  GOALS 

The  detailed  packaging  goals  of  Class  Structuring  depend  on  the  spedfic  properties  you  want  the 
spedfication  to  have,  'typical  goals  are  to  create  a  specification  that  is  easy  to  read  and  understand, 
supports  reuse,  supports  independent  development  (e.g.,  for  risk  mitigation),  minimizes  the  effect  of 
fu^  requirements,  and  is  stable  with  respect  to  likely  changes.  Of  these,  you  will  always  be  concerned 
with  controlling  the  effects  of  requirements  changes.  Your  goal  is  to  encapsulate  parts  of  the  spedfica¬ 
tion  likely  to  change  and  define  dass  interfaces  that  are  unlikely  to  diange.  You  must  have  a  reason- 
stable  set  of  dasses  and  dass  interfaces  to  be  able  to  address  other  packaging  concerns,  such  as 
reuse  or  independent  development. 

In  this  activity,  you  create  the  dass  structure  based  on  the  padcaginggoals.  You  allocate  the  behavioral 
model  to  classes  and  define  the  class  interfaces  to  satisfy  both  the  behavioral  modeling  goal  of  defining 
the  controlled  variable  functions  and  the  padtaging  goals,  such  as  ease  of  change. 

If  your  overall  packaging  goals  have  not  been  dedded  as  part  of  the  system  design,  you  should  dedde 
now  how  important  each  of  these  goals  is  relative  to  specific  parts  of  the  requirements.  For  example, 
the  specification  cannot  be  equally  eaty  to  diange  for  all  possible  dianges.  You  must  dedde  whidi 
changes  are  most  important  to  accommodate  and  how  likely  each  diange  is;  this  lets  you  set  the  more 
practical  goal  of  maldng  a  certain  set  of  requirements  easy  to  diange.  Similarly,  you  must  dedde  whidi 
parts  of  the  requirements  you  are  likely  to  reuse,  where  fuzzy  requirements  represent  a  problem  that 
must  be  controlled,  and  so  on.  Identifying  these  goals  gives  you  a  basis  for  making  rational  dedsions 
about  how  the  requirements  should  be  packaged. 
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^thin  the  context  of  your  specific  padcaging  goals,  you  have  the  following  overall  aims: 

•  Create  boundary  classes  that  abstract  from  details  about  the  software's  interface  with  the 
environment  and  encapsulate  variables  and  the  REQ,  IN,  and  OUT  relations  (boundary 
classes). 

•  Create  classes  that  provide  mode  information  and  encapsulate  the  detailed  specifications  of 
mode  machines. 

•  Qeate  classes  that  encapsidate  fuzzy  or  diai^eable  requirements. 

•  Minimize  the  dependencies  among  classes. 

You  create  the  following  work  products  in  the  Class  Structuring  activity: 

•  A  definition  of  each  dass  interface  and  its  encapsulation  structure 

•  One  or  more  dependen<7  graphs  showing  the  dependency  relation  among  classes 

9J2  ENTRANCE  CRITERIA 

Before  beginning  Class  Structuring,  you  should  have  completed  the  Preliminary  Behavior 

Spedfication  activity  and  have  the  following  work  products: 

•  A  definition  for  each  monitored  and  controlled  variable 

•  Overviews  of  the  controlled  variable  function  domains,  including  the  monitored  variables,  the 
modes  needed,  and  the  scheduling  requirements 

•  Initial  definitions  of  the  ^tem  modes 

•  Any  specification  of  packaging  goals  from  ^tems  engineering  or  prior  CoRE  activities, 
induding: 

-  A  list  of  antidpated  requirements  changes 

—  A  list  of  furdamental  stabilities  and  aspects  of  the  requirements,  problem,  and  system 
not  expecteu  change 

93  CLASS  STRUCIXlRINGACTIVmES 

Class  Structuring  comprises  the  following  activities: 

•  Create  Boundary  Classes.  Identify  and  create  those  classes  that  contain  the  definitions  of  the 
monitored  and  controlled  variables. 

•  Create  Mode  Classes.  Create  the  dasses  that  encapsulate  mode  machine  definitions  and 
provide  mode  information. 

•  Create  Term  Classes.  Identify  and  aeate  classes  that  provide  any  terms  not  provided  by  the 
boundary  and  mode  dasses. 
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•  Define  the  Encapadation  Structure.  Identify  those  dasses  that  will  encapsulate  the  definitions 
of  other  dasses  and  develop  the  encapsulated  dass  structure. 

•  Define  die  GmeraiiziationlSpeciaUzution  Structure.  Identify  common  elements  of  the  behavioral 
model  and  package  them  as  a  superclasses.  Create  the  superclass  and  subclass  definitions. 

•  EsteMish  D^endencies.  Establish  and  document  which  classes  use  what  information  provided 
by  other  dasses  and  evaluate  the  dass  structure  based  on  your  packaging  goals. 

In  i^actice,  you  typically  begin  developing  the  dass  structure  by  creating  a  dependent^  grai^  to 
illustrate  the  effects  ofyour  packagiitgdedsions.  Begin  creating  the  boundary  dasses.  First  allocate 
the  monitored  and  controUed  variables  to  dasses,  seating  a  partial  dependency  graj^  showing 
boundary  dasses  and  the  monitored  and  controUed  variables.  Work  to  connect  the  dasses  defining 
controUed  variables  and  their  functions  to  the  classes  providing  monitored  variables,  terms,  and 
modes.  Add  mode  classes  and  show  which  dasses  depend  on  whicdi  mcxles.  Add  dasses  to  encapsulate 
groups  of  terms  that  you  wish  to  pacdcage  tc^ether,  and  show  how  other  classes  depend  on  those  terms. 
You  have  completed  the  Class  Structuring  adivify  when  aU  of  the  elements  of  the  behavioral  model 
have  been  allocated  to  some  class  and  the  depenclency  graph  for  each  enc:apsulation  structure  shows 
all  of  the  dependendes  between  those  dasses. 

Repeat  the  pr<x:ess  of  partitioning  the  behavioral  model  into  classes  and  showing  the  dependendes 
in  inaeastng  levels  of  detail  as  you  decompose  class  definitions  into  further  classes.  You  have  com¬ 
pleted  the  entire  Class  Structuring  activity  when  the  entire  behavioral  model  is  all(x:ated  to  some  part 
of  thedass  structure,  when  no  dass  wiU  be  further  decomposed,  and  when  aU  of  the  dependendes  have 
been  identified. 

93.1  Create  Boundary  Classes 

In  this  activity,  you  create  the  boundary  classes.  A  boundary  class  defines  monitored  and  controUed 
variables  and  potentially  encapsulates  the  corresponding  variables  and  the  REQ,  IN,  and  OUT  rela¬ 
tions.  Define  the  boundary  class  interface  to  provide  the  definitions  of  monitored  variables  that  are 
used  by  other  classes.  Spedfy  terms  on  the  interface  that  provide  information  about  the  monitored 
variables  defined  by  the  class. 

This  section  provides  heuristics  that  help  guide  your  dedsions  about  which  parts  of  a  boundary  class 
spedfication  should  be  encapsulated  and  which  parts  should  be  defined  on  the  interface. 

93.1.1  Allocate  Monitored  and  ControUed  Wiriables 

B^in  creating  the  boundary  dasses  by  aUocating  the  set  of  monitored  and  controlled  variables  among  a 
set  of  boundary  dasses.  Allocate  the  variables  to  boundary  dasses  by  applying  the  foUowing  heuristics. 

•  Assign  to  the  same  dass  those  variables  whose  definitions  are  likely  to  change  together.  Use 
information  about  stabilities  in  the  requirements  to  help  identify  variables  likely  to  change 
together. 

•  Assign  to  different  dasses  those  variables  whose  definitions  are  likely  to  change 
independently.  Use  the  list  of  likely  changes  to  help  you  dedde  which  variable  definitions  are 
likely  to  change  independently. 
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•  Where  there  are  relationships  between  environmental  variables  you  must  preserve,  allocate 
these  to  the  same  dass.  For  example,  allocate  variables  to  the  same  class  where  the  variables 
are  part  of  a  coherent  abstraction. 

If  you  created  an  information  model  in  the  Identify  Environmental  Variables  activity,  use  the  entities 
ai^  relationships  in  the  model  to  help  make  dedsions  about  whether  particular  variables  should  be 
allocated  to  the  same  dass.  Examine  each  of  the  entities  in  the  model  to  determine  whether  the  envi¬ 
ronmental  variables  re|xresented  by  the  model’s  attributes  are  related  and  should  be  part  of  the  same 
dass.  For  example,  consider  vdiether  an  entity  and  its  attributes  represent  a  single  coherent  abstrac¬ 
tion.  Consider  'idiether  a  set  of  monitored  variables  assodated  with  an  entity  must  be  evaluated 
together.  Consider  whether  a  set  of  controlled  variables  assodated  with  an  entity  must  be  set  together. 

Examtlez  Consider  the  information  model  and  list  of  likely  changes  developed  in  Section  7. 
Ihble  7-4  lists  the  ELMS  entities  and  attributes.  For  this  example,  the  elements  of  the  operator 
interface  are  likely  to  change  together  because  they  are  all  handled  by  the  same  device.  Create 
class_Operator  and  allocate  variables  mon_Res6t_Switch.  mon_Selftest_Switch. 
con_Low_Alarm,  con_Hlgh_Alarm,  and  con_Audlble_AlarTn  to  it. 

93.1.2  Define  the  Boundary  Class  Interface 

Use  the  dedsions  you  have  made  about  allocating  monitored  variables  to  classes  as  well  as 
information  about  the  behavioral  model  (e.g.,  from  the  Preliminary  Behavior  Spedfication  activity) 
to  dedde  which  monitored  and  controlled  variables  (if  they  are  also  treated  as  monitored)  and  terms 
wQl  be  provided  on  the  class  interface.  Summarize  your  dedsions  about  what  information  the  dass 
will  provide  in  the  Class  Desaiption  (see  Ihble  5-3). 

Monitored  and  Controlled  Variables.  You  may  choose  to  encapsulate  an  environmental  variable  or 
allow  it  to  be  used  elsewhere  in  the  spedfication.  Use  the  preliminary  behavior  spedfication  to  deter¬ 
mine  whether  you  need  the  value  of  the  variable  (e.g.,  to  define  some  controlled  variable  function) 
or  if  you  need  information  about  the  variable  (e.g.,  a  predicate  on  its  value). 

Provide  the  definition  of  a  monitored  variable  on  the  interface  only  if  that  variable  is  needed  in  the 
definitions  of  other  classes.  Provide  the  definition  of  a  controlled  variable  on  the  interface  only  if  the 
variable  is  both  monitored  and  controlled  by  the  software.  If,  instead,  some  property  of  the  variable 
or  a  set  of  variables  is  needed,  define  a  term  providing  the  needed  information. 

If  the  variable  is  encapsulated,  its  definition  must  appear  only  in  the  Encapsulated  Information 
section  of  the  dass  spedfication.  Otherwise,  the  definition  appears  in  the  Class  Interface  section. 

Example:  Allocate  the  monitored  variable  mon_FueI_Level  to  class_Fuel_Tank.  Because  the 
monitored  variable  is  needed  by  other  dasses  (e.g.,  to  describe  the  value  function  for 
con_Level_Display),  put  the  definition  on  the  dass  interface  (see  Figure  9-1). 

Terms.  In  this  activity,  you  spedfy  any  terms  provided  by  the  boundary  class.  Provide  terms  on  the 
interface  to  abstract  from  details  of  the  environmoital  variables.  Reduce  complexity  by  defining  terms 
that  provide  only  information  about  the  variables  that  are  actually  needed  to  define  other  dasses. 
Manage  diange  by  defining  terms  that  provide  only  the  information  that  is  not  likely  to  change  while 
abstracting  from  details  likely  to  change. 
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CLASS_FUEL_TANK 

dass_F\iel_Ikiik  provides  the  information  needed  to  determine  the  current  fuel  level;  whether  the  fuel  level  is 
above,  below,  or  within  safe  limits;  and  whether  the  fuel  level  is  within  the  hysteresis  bounds.  It  encapsulates 
the  constants  and  rules  for  determining  whether  the  fuel  level  is  within  safe  or  hysteresis  limits.  It  also  encapsu¬ 
lates  how  the  software  can  determine  the  values  of  mon  Fbel  Level  and  mon  Ftiel  Level  Unknown. 


Class  INURFACE 

Name 

mon  Fbel  Level 


Enviroiunental  VariaUe  Glossary 
lype  \bhies  Precision  Physical  Interpretation 


LENGTH  0.0.30.0.  03 


mon  1^1  Level  Unknown  BOOLEAN  false 


true 


Level  of  fuel  in  the  tank,  in  centimeters 
(cm),  along  the  vertical  axis  on  the  left 
side  of  the  tank,  S  cm  from  the  front 
edge.  The  level  is  measured  with  respect 
to  the  scale. 

The  system  is  able  to  obtain  the 
information  required  to  determine  the 
value  of  fuel  level  to  the  required 
accuracy. 

The  system  is  unable  to  obtain  the 
information  required  to  determine  the 
value  of  fuel  level  to  the  required 
accurar^. 


Constants,  Events,  and  Ibrms  Other  Classes  Are  Allowed  to  Use 


Name 

teim_Fhel_Level_Range 
term_Inside_Hys_Range 

Ennrinnunent-Imposed  Behavior  (NA1) 

frnon  Fuel  Level! 


^mon  Fuel  Level  ^ 

— T-= — sir -  ^  const  Max  Level  Rate 

dmon  Ttme  _  _  _ 


-0.4  cm  ^  mon  Fbel  Level  ^  30.0  cm 


Iugure9-1.  Partial  Definitions  (^cIass_FuelJ13uik 


Use  the  Fteliminary  Behavior  Spedfication,  the  set  of  environmental  variables  defined  by  the  dass, 
and  your  packaging  constraints  (e.g.,  list  of  likely  changes)  to  dedde  which  terms  the  class  should  pro¬ 
vide  on  its  interface.  Use  the  Preliminary  Behavior  Spedfication  to  identify  whidi  terms  are  ne^ed 
that  are  a  function  of  the  variables  defined  by  the  dass.  Use  the  packaging  constraints  to  dedde  wiiat 
information  about  those  terms  must  be  provided  on  the  interface.  Apply  the  following  heuristics  to 
dedde  which  terms  you  should  create: 
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•  Where  the  meaning  of  a  monitored  variable’s  value  rather  than  the  value  of  the  variable  itself 
is  needed  by  other  classes,  create  a  term  that  captures  the  properties  other  dasses  need. 

Ex4Mn&  An  avionics  system  monitors  the  weight-on-gear  switdi  to  determine  whether  the 
aircraft  is  airborne.  It  is  the  information  about  the  state  of  the  aircraft  that  is  needed  by  other 
classes,  so  you  should  create  a  condition  modeling  whether  the  airaaft  is  airborne. 

class_Operator  defines  a  monitored  variable  that  denotes  the  state  of  the  reset  switch 
(mon_Reset_Swttch).  The  software  determines  whether  a  reset  has  occurred  based  on  how 
long  the  switch  is  held  down  (at  least  3  seconds).  However,  the  essential  information  needed 
to  write  the  other  classes  is  that  a  reset  has  occurred,  not  the  state  of  the  switdi.  Abstract  from 
the  arbitrary  rules  for  determining  that  a  reset  has  occurred,  and  provide  the  essential  in¬ 
formation  by  creating  the  event_Reset  event  that  occurs  when  all  of  the  conditions  satisfying 
a  reset  become  true. 

•  Where  the  actual  quantities  monitored  are  only  a  means  for  getting  another  value, 
encapsulate  the  monitored  quantities  and  define  a  term  providing  the  needed  value.  For  exam¬ 
ple,  this  can  occur  when  the  required  quantities  are  relative  measures  among  variables.  In  such 
cases,  provide  the  needed  value  on  the  interface  and  encapsulate  the  monitored  variables  and 
other  information  needed  to  derive  the  value. 

^CAMPLE:  For  an  aircraft  collision  avoidance  ^tem,  the  system  fypically  monitors  the 
current  positions  of  the  host  aircraft  and  any  threat  aircraft.  Which  aircraft  represents  a  threat 
depends  on  its  relative  position,  heading,  and  velodty.  The  interface  for  a  dass  that 
encapsulates  the  airaaft  position  might  provide  information  for  such  relative  measures. 

•  Where  there  are  arbitrary  constraints  or  constants  that  add  complexity  or  are  likely  to  change, 
define  a  term  that  captures  the  essential  information  about  the  environmental  quantities  and 
encapsulate  the  details. 

Example:  class_Fuel_Tank  defines  the  monitored  variables  mon_Fuel_Level  and 
mon_Fuel_Level_Unknown.  You  have  determined  that  the  cunent  operating  mode  of  the  sys¬ 
tem  depends  on  the  state  of  the  fuel  level.  In  particular,  it  depends  on  whether  the  fuel  level 
is  too  low,  too  high,  or  within  safe  limits.  The  operating  mode  also  depends  on  whether  the 
fuel  level  is  within  certain  hysteresis  limits  (to  ensure  stable  transitions). 

Other  classes  must  use  information  about  whether  the  fuel  level  is  within  safe  limits  or  within 
the  hysteresis  limits  to  determine  the  current  mode  or  sound  an  alarm.  However,  other  classes 
need  not  use  or  depend  on  the  specific  constants  that  determine  vliat  the  limits  are. 

The  definition  of  class_Fuel_Tank  addresses  these  packaging  concerns  by  providing  two  terms 
on  the  interface:  term_Fuel_Level_Range,  an  expression  denoting  whether  the  current  fuel 
level  is  too  low,  too  high,  or  within  limits,  and  termJnside_Hys_Range,  a  predicate  indicating 
whether  the  current  fuel  level  is  within  the  hysteresis  bounds  (see  Figure  9-1).  The  definitions 
of  the  terms  and  the  related  constants  are  given  in  the  encapsulated  information  for  the  class 
(See  Appendix  B,  Section  B.4). 
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9J.2  Create  Mode  Classes 


In  this  activity,  you  create  the  classes  that  encapsulate  mode  machines  and  create  the  interface  for 
each  mode  madiine.  The  class  interface  provides  information  about  the  current  mode  and  mode  tran¬ 
sitions  that  can  be  used  to  define  the  behavioral  model.  It  encapsulates  the  detailed  definition  of  the 
mode  machine,  such  as  which  events  result  in  which  specific  transitions. 

Each  mode  machine  must  be  allocated  to  one  mode  class.  Create  the  mode  classes  based  on  the  mode 
machines  you  identified  in  the  Preliminary  Behavior  Specification  activity. 

Define  a  mode  class  interface  by  providing  the  information  that  other  classes  are  allowed  to  use  about 
the  mode  machine.  You  have  few  decisions  to  make  about  the  class  interface  because  the  class 
definition  is  constrained  to  provide  only  certain  mode  information  as  follows: 

•  All  of  the  modes  of  the  class  must  be  defined  on  the  interface  (to  support  completeness 
checking) 

•  The  events  ENTERED(m)  and  EXITED(m)  are  defined  for  each  mode  m  on  the  interface 

•  The  condition  INMODE(/n)  is  defined  for  each  mode  m  on  the  interface 

lb  define  the  interface,  use' the  form  provided  in  Section  5-3.  For  erample,  you  would  create  a  dass 
to  encapsulate  the  definition  of  the  mode  machine  for  the  FLMS  as  shown  in  Figure  9-2.  The  interface 
definition  provides  the  names  of  the  modes  of  the  mode  machine  for  the  FLMS  (see  Section  8.3.3.1). 

CLASS_IN_OPERATION 

dass_In_C>peration  defines  the  FLMS  modes.  It  encapsulates  the  rules  for  determining  the  current  mode  and 
the  events  that  trigger  transitions  among  the  modes. 

Class  Interface 

Modes  Other  Classes  Are  Allowed  to  Use 

Mode 

mode_Operating 

mode_Hazard 

mode_Shutdown 

modeJTest 

mode_BadLevDev 

Constants,  Events,  and  Terms  Other  Gasses  Are  Allowed  to  Use 

Name 

term_Test_Time 

ingi]re9-2.  Mode  Class  Interface  Examine 

933  Create  Term  Classes 

In  this  activity,  you  create  any  additional  classes  needed  to  provide  terms  that  are  not  provided  by  the 
boundary  classes.  Create  a  class  that  defines  additional  terms  from  the  monitored  variables  or  other 
terms  under  the  following  circumstances: 
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•  The  information  needed  is  an  expression  of  two  or  more  monitored  variables  defined  in 
different  boundary  classes  or  used  to  define  the  controlled  variable  functions  or  inodes  in  two 
or  more  classes. 

•  Some  subset  of  the  requirements  represents  a  distinct  concern  relative  to  the  packaging  goals. 

•  The  spedfication  is  simpler  if  you  define  a  class  that  abstracts  from  the  details  of  some  part 
of  the  requirements. 

Use  the  controlled  variable  overviews,  boundary  classes,  change  fist,  and  any  additional  information 
from  the  system  specification  to  identify  shared  information  that  should  be  provided  a  term  dass. 
In  general,  the  same  criteria  that  govern  the  creation  of  terms  on  boundary  class  interfaces  also  govern 
the  creation  of  term  class  interfaces. 

Examples  An  aircraft  collision  avoidance  ^tem  monitors  the  position  of  other  airaaft  relative  to 
the  host,  determines  the  threat  of  collision  for  each,  and  provides  a  visual  display  of  the  current  threat 
status  to  the  j^ot  Hie  aircraft  that  represent  a  potential  threat  are  dassified  aoccffding  to  a  set  of  rules 
determined  by  the  Federal  Aviation  Administration.  Because  these  rules  represent  data  that  indepen¬ 
dently  changes  from  the  rest  of  the  spedfication  and  the  required  behavior  of  the  di^lay  depends  onfy 
on  the  threat  class  (not  on  vdiat  determines  the  rules  that  determine  the  threat  dass),  tl^  spedfication 
is  dearer  and  easier  to  diange  if  the  Federal  Aviation  Administration  rules  are  encapsulated  in  a  term 
dass. 

93.4  Dehnethe  ENCAPSULjaioN  Structure 

In  this  activity,  you  identify  and  define  encapsulated  classes.  Make  a  first  pass  at  defining  the 
encapsulation  structure  following  Preliminary  Behavior  Specification  based  on  the  information 
allocated  to  each  class.  Revisit  this  activity  during  the  subsequent  Detailed  Behavior  Spedfication 
activity  as  the  detailed  requirements  are  better  understood. 

Define  encapsulated  classes  when  doing  so  addresses  your  packaging  goals.  You  create  encapsulated 
classes  following  the  same  guidelines  and  heuristics  by  which  you  created  the  higher  level  (in  the  en¬ 
capsulation  hierarchy)  class  structure,  e.g.,  if  additional  organization  into  dasses  helps  reduce 
complexity,  manage  change,  and  so  on. 

If  you  developed  an  information  model,  examine  the  model  for  any  is-part-of  relations.  If  there  are 
requirements  that  apply  to  the  whole  structure  rather  than  individually  to  the  parts,  consider  defining 
the  structure  as  a  class  and  the  components  as  encapsulated  classes. 

You  should  stop  decomposing  into  encapsulated  classes  when  each  class  satisfies  your  padtaging 
goals,  each  class  is  understandable,  the  information  in  a  class  is  related,  the  information  in  a  dass  is 
likely  to  change  together,  and  so  on. 

Examples  class_Operator  encapsulates  how  the  FLMS  is  required  to  interact  with  the  operator 
and  the  mechanisms  available  to  the  software  to  support  the  required  interactions.  >Mthin 
class_Operator,  the  outputs  to  the  operator  and  the  inputs  from  the  operator  represent  parts  of 
the  spedfication  that  can  be  usefully  represented  as  two  encapsulated  classes. 

The  controlled  variables  (con_Audible_Alarm,  con_High_Alarm,  etc.)  sent  to  the  operator  satisfy 
Core’s  heuristics  for  dass  formation  in  several  ways.  First,  all  of  the  outputs  use  the  same  hardware 
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device  so  they  share  parts  of  the  OUT  relation.  Second,  because  they  share  the  same  hardware,  they 
are  also  likely  to  change  together  if  the  display  hardware  changes.  Finally,  they  are  temporally  related 
because  the  alarms  and  displays  must  be  up^ted  to  reflect  the  conditions  the  alarms  are  signaling. 

The  monitored  variables  from  the  operator  (mon_Selftest_Switch  and  mon_Reset_Switch)  do  not 
share  hardware  with  the  controlled  variables,  are  likely  to  change  independently  of  those  variables, 
and  have  some  reasonable  expectation  of  changing  together.  Thus,  the  switches  should  be  defined  in 
a  distinct  class. 

Create  the  interface  for  class_Operator  by  showing  which  variables  and  terms  are  defined  by  the 
encapsulated  classes  and  exported  by  class_Operator.  These  are  the  events  event_Selftest  and 
event_Reset.  Create  the  encapsulated  information  by  providing  the  definitions  of  the  two  encapsu¬ 
lated  classes  and  the  dependency  graph  of  the  encapsiilated  classes.  The  interface  and  dependency 
graph  are  shown  in  Figure  9-3.  The  definitions  of  class_Operator_Communication  and  class_Switch 
classes  are  given  in  Appendix  A. _ 

OASS.OPERATOR 

class_Operator  encapsulates  how  the  FLMS  is  required  to  interact  with  the  operator  and  the 

mechanisms  available  to  the  software  to  support  the  required  interactions. 

Class  Interface 

Constants,  Events,  and  Terms  Other  Classes  Are  Allowed  to  Use 

event_SeIftest 
event_Reset 

Encapsulated  Information 

Classes  Defined 


term  Test  Time 


mode_class_In_Operation 


_  ,  ,  ,  ,  con  High  Alarm 

term  Fuel  Level  Range  j  j - 

- = - I  oan_Low_Alann 

mon  Fuel  Level 


mon  Tune 


mon  Selftest  Switch 


con  Audible  Alarm 


con_Level_Di^lay 


event  Selftest 


mon  Reset  Switch  1  «'«»-Switch  )  event_Reset 


Figure  9-3.  Dependency  Graph  for  Opmtor  Interface 


93  J  Define  the  GENERAUZATiON/SPECiAUZAnoN  Structure 

If  you  have  identified  cases  where  two  or  more  classes  have  common  requirements,  you  may  choose 
to  represent  the  commonality  by  creating  a  superclass.  In  CoRE,  you  use  the  superclass  mechanism 
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for  both  representing  requirements  more  compactly  and  for  making  the  commonality  in  requirements 
explicit  to  others  using  the  requirements  (e.g.,  the  designers).  This  means  that  you  should  use  the  su¬ 
perclass  mechanism  only  if  the  commonality  embodied  in  the  superclass  represents  an  essential  part 
of  the  problem  you  do  not  expect  to  change.  Conversely,  you  should  not  use  it  to  represent  incidental 
or  accidental  commonality. 

If  you  developed  an  information  model,  you  may  have  identified  potential  superclass  or  subdass 
relationships  in  the  form  of  is-a  relations.  Otherwise,  use  information  on  common  parts  of  the  specifi¬ 
cation  developed  in  this  and  previous  activities  to  identify  potential  superclass  or  subclass 
relationships. 

Example:  The  RICPs  and  CDU  share  all  the  display  and  much  of  their  data  entry  characteristics. 
Further,  these  characteristics  are  essential  to  the  problem  and  potentially  useful  to  future  design¬ 
ers  as  discussed  in  Section  5.  You  choose  to  create  a  superclass_Radio_Display  to  represent  the 
parts  of  the  behavior  specification  common  to  the  RTCPs  and  CDU.  You  identify  the  following 
as  common  elements: 

•  mon_Radio_Selectlon  is  a  monitored  variable  assuming  one  of  six  values  (UHF1 ,  UHF2, 
VHF1 ,  VHF2,  HF1 ,  HF2)  indicating  which  radio  the  pilot  has  selected. 

•  mon_Scratchpad_String  is  an  alphanumeric  string  entered  into  the  scratchpad. 

•  con_Scratchpad  can  clear  or  blink  the  scratchpad  contents. 

•  con_Display_Line  displays  the  current  frequency  of  each  radio. 

Define  each  of  these  variables  on  the  interface  of  superclass_Radio_Display.  Then  define  two 
subclasses  as  follows: 

•  class_RTCP  adds  no  additional  information,  but  its  definition  constrains  the  type  of 
mon  Scratchpad_String  to  be  numeric  because  there  are  no  alphabetic  keys  on  the 
KTCP. 

•  class_CDU  adds  two  monitored  variables  to  repiesent  a  preset  frequency  and  a 
mnemonic.  It  also  adds  two  terms  representing  a  valid  preset  and  a  valid  mnemonic  being 
received. 

You  then  define  class_CDU  as  shown  in  Figure  94. 

93.6  Estabush  Dependencies 

In  this  activity,  you  establish  how  classes  depend  on  one  another.  In  CoRE,  a  class  X  depends  on  class 
Y  if  X  uses  a  term  provided  on  the  interface  of  Y  in  its  definition.  The  number  and  kind  (i.e.,  which 
mcxles  and  terms  a  class  depends  on)  of  dependencies  help  you  determine  how  well  the  class  structure 
meets  packaging  goals  like  ease  of  change. 


9-10 


9.  Class  Structuring 


CLASS_CDU 
Class  Description 

dass_CDU  is  a  subclass  of  superclass_Radio_Display.  It  encapsulates  the  rules  for  entering  radio  frequencies 
as  presets  and  mnemonics  and  for  determining  if  a  preset  or  mnemonic  is  valid.  It  provides  conditions  denoting 
a  preset  or  mnemonic  selected,  the  radio  selected,  and  the  string  entered. 

Class  Interface 

Defines:  term_Valid_Preset 

term_Valid_Mnemonic 

mon_Scratchpad_String.CDU 

mon_Radio_Selection.CDU 

\ 

Encapsulated  Information 

Dependency  Graph 


mon_ScTatchpad_String 
mon  Radio  Selection 


mon_Scratcfapad_String 
nion_Radio_Selection 
Radio_lMspiay  j  con_Display_Line 


mon  Radio  lelection 


mon  Preset 


mon  Mnemonic 


conScratchpad 


tenn  V^id  IVeset 


term  VUid  Mnemonic 


Figure  9-4.  Generalization/Spedalization  Biample 


You  are  likely  to  find  additional  dependendes  or  change  existing  ones  during  Detailed  Behavior 
Specification.  For  example,  you  may  find  that  you  cannot  write  the  functions  for  a  particular  controlled 
variable  without  using  an  additional  monitored  variable.  However,  to  understand  the  implications  of 
your  class  structuring  dedsions  and  evaluate  those  dedsions  against  the  packaging  goals,  you  need  an 
initial  set  of  dependendes. 

The  goal  of  this  activity  is  to  identify  and  record  the  dependendes  between  the  classes.  Tb  perform 
this  activity,  you  need  the  class  definitions.  The  product  of  this  activity  is  the  dependency  graphs  that 
show  exactly  which  class  uses  which  environmental  variable,  term,  event,  or  mode  machine.  Create 
a  dependency  graph  for  each  distinct  part  of  the  Encapsulation  Structure;  i.e.,  each  set  of  classes  that 
are  encapsulated  by  the  same  parent  class  will  have  a  distinct  dependency  graph. 

In  an  idealized  view  of  the  process,  you  create  the  dependency  graphs  after  defining  the  class 
interfaces  because  you  cannot  complete  the  graphs  until  the  class  spedfications  are  complete.  In 
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practice,  you  begin  constructing  the  dependency  graph  in  parallel  with  dioosing  the  dasses  and 
defining  dieir  interfaces  because  the  graph  illustrates  the  consequences  of  your  choices  and  helps 
guide  subsequent  dedsions. 

You  create  a  dependency  graph  for  the  classes  you  have  defined,  lb  create  a  dependency  graph, 
examine  each  class  in  turn.  Determine  which  of  the  terms  defined  in  other  dasses  are  used  to  define 
the  cnurent  class’s  interface  or  is  needed  to  define  its  encapsulated  information.  Use  the  dependency 
graph  notation  defined  in  Section  5.3.2. 

Example:  Figure  9-5  shows  a  partial  dependency  graph  for  the  FLMS.  6ec:ause  the  mcxle 
machine  in  class  Jn_Operation  changes  mcxles  if  a  self-test  cxxmrs,  it  uses  event_Selftest  in  the 
definition  of  the  mode  transition  table.  Thus,  ciass_ln_Operation  depends  on  class_Operator. 
Draw  an  arrow  from  the  class_Operator  bubble  to  the  classJn_Operation  bubble  and  label  it 
event_Setftest 

Similar^,  the  modes  defined  by  classJn_Operation  are  used  to  define  the  controlled  variable 
functions  in  both  class_Operator  and  class_Pump.  Create  a  dependency  from  the 
classJn_Operation  to  each  class  using  the  mode  machine. 

You  have  finished  establishing  dependencies  when  there  is  a  dependency  for  every  term  that  is  defined 
by  one  class  and  used  by  another.  In  practice,  the  exact  dependencies  between  classes  become  better 
understcxxi  and  change  during  subsequent  development,  especially  in  the  Detailed  Behavior  Specifi- 
c:ation  activiy ,  You  need  to  iterate  the  entire  development  prcx^ess  to  identify  the  dependencies  fully. 

9.4  EVALUATION  CRITERIA 

On  eacii  iteration  and  upon  finishing  the  specification,  evaluate  the  packaging  and  interface  creation 
decisions  against  your  objectives. 

9.4.1  Evaluating  Classes 

Evaluate  the  classes  chosen  and  the  class  interfaces  against  both  general  criteria  and  the  specific 
packaging  goals  established  for  your  specification.  General  criteria  to  consider  are: 

•  Appropriate  Abstraction.  Each  of  the  class  interfaces  you  create  provides  information  used  to 
define  other  classes  (e.g.,  to  write  the  controlled  variable  functions).  The  interface  is  consid¬ 
ered  a  gocxl  one  if  it  provides  an  abstract  representation  of  the  information  defined  in  the  class 
that  is  easy  to  imderstand  and  use.  Verify  that  the  names  used  clearly  indicate  the  content  of 
each  term,  that  each  term  is  well  defined,  and  that  the  interface  is  as  simple  as  possible  while 
providing  the  information  needed  by  other  classes.  Check  the  number  of  dependendes  origi¬ 
nating  in  the  class;  if  the  number  is  large,  look  for  a  simpler  interface  or  consider  creating  an 
additional  class. 

•  Appropriate  Encapsulation.  Evaluate  each  class  to  ensme  that  the  division  of  the  requirements 
into  classes  provides  appropriate  separation  of  concerns.  Verify  that  the  class  description 
makes  clear  what  information  the  class  encapsulates.  Verify  that  the  class  interface  does  not 
provide  information  that  should  be  encapsulated;  i.e.,  check  that  each  piece  of  information 
provided  by  the  interface  is  not  part  of  the  information  the  class  should  encapsulate. 
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Figure  9-5.  Fuel  Level  Monitmng  System  Dependency  Graph 

Each  class  should  encapsulate  related  information.  Verify  that  the  requirements  in  a  class  can 
change  together.  If  they  change  independently,  consider  creating  an  additional  class. 

You  must  also  evaluate  the  class  structure  against  any  specific  packaging  goals  you  established.  For 
example: 

•  Chtmge  Management,  For  each  requirement  considered  likely  to  change,  trace  the  requirement 
to  the  defim'ng  class.  Verify  that  the  requirement  is  encapsulated  by  the  class.  If  a  requirement 
that  is  likely  to  change  is  on  a  class  interface,  reexamine  the  class  interface  to  see  if  it  can  be 
hidden. 

•  Fiaizy  Requirements.  Limit  the  impact  of  fuzzy  requirements  by  encapsulating  the  fuzs^ 
requirement  in  a  class.  For  such  cases,  verify  that  any  fuzzy  requirements  are  encapsulated  by 
a  class. 
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•  Rnae.  The  class  is  typically  the  atomic  unit  of  reusability  in  a  CoRE  specification.  Verify  that 
each  reusable  component  is  encompassed  by  a  class  definition  and  that  the  class  jn-ovides  an 
appropriate  abstraction. 

•  I&sk  Mit^athn.  Verify  that  each  set  of  related  requirements  considered  risky  is  allocated  to 
a  distinct  class  and  that  the  class  interface  is  well  defined.  You  can  then  proceed  with  the  design 
and  implementation  of  that  class,  independent  of  the  other  dasses,  until  the  risk  issues  are 
suffidently  resolved. 

9.4.2  Evaluating  Class  Dependencies 

The  dependency  graph  allows  you  to  evaluate  the  requirements  architecture  against  the  packaging 
goals.  For  sample,  you  must  determine  whether  the  structure  easily  accommodates  the  dianges  you 
identified  as  likely. 

•  Closure.  Use  the  preliminary  behavioral  model  and  the  dependency  graph  to  determine 
whether  you  have  identified  all  the  information  needed  to  write  the  controlled  variable 
functions. 

-  Evaluate  each  boundary  class  that  defines  a  controlled  variable  to  determine  if  the 
monitored  variables,  terms,  and  modes  used  (as  shown  ly  the  dependency  graph)  are 
adequate  to  define  the  controlled  variable  functions  (as  identified  in  Preliminary 
Behavior  Specification). 

-  Examine  the  classes  that  define  modes  or  terms  used  by  the  boundary  classes.  For  each 
class,  ensure  that  the  terms  or  modes  provided  by  the  object  are  defined  using  the 
information  used  by  the  object  (as  shown  by  the  dependency  graph). 

•  Change  Management.  If  acing  dependencies  allows  you  to  analyze  the  effect  of  changes  to  a 
class  interface  on  other  parts  of  the  requirements.  For  each  ciiange  that  you  identify  that 
appears  on  a  class  interface,  trace  the  dependencies  and  determine  which  other  classes  will 
be  affected  by  the  change.  If  there  are  a  relatively  large  number  of  dependencies  on  these  or 
any  other  interface  requirements,  consider  altering  the  interface  to  reduce  the  dependencies. 

93  EXIT  CRITERIA 

Class  Structuring  is  complete  when: 

•  All  the  elements  of  the  behavioral  model  (i.e.,  all  the  variables  and  relations)  have  been 
allocated  to  some  class. 

•  Classes  and  class  interfaces  have  been  defined. 

•  The  Encapsulation  Structure  is  defined. 

•  The  Generalization/Specialization  Structure  is  defined. 

•  All  the  dependencies  are  shown  on  the  dependency  graphs. 
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In  the  Detailed  Behavior  Specification  activity,  you  complete  the  specification  of  the  behavioral 
model  relations  except  for  IN  and  OUT.  You  use  the  controlled  variable  overviews  you  developed  in 
Freliminaiy  Behavior  Specification  and  the  class  definitions  you  developed  in  Qass  Structuring  to 
perform  the  following  activities: 

•  Develop  a  detailed  specification  of  the  value  function  for  each  controlled  variable. 

•  Develop  a  detailed  specification  of  the  scheduling,  timing,  and  tolerance  constraints  for  each 
controlled  variable. 

•  Complete  the  specification  of  each  mode  machine. 

•  Revisit  the  class  structuring  decisions. 

When  you  have  finished  this  activity,  you  will  have  completed  the  definition  of  the  encapsulated 
information  for  each  class  except  for  the  definitions  of  the  input  and  output  variables  and  the  IN  and 
OUT  relations  (the  subject  of  Section  11). 

10.1  GOALS 

The  goal  of  this  activity  is  to  complete  the  behavioral  model  specification.  This  includes: 

•  A  complete  specification  of  required  behavior  for  each  controlled  variable  as  follows: 

—  A  spedfication  of  the  controlled  variable  value  function  that  is  com^dete  and  consistent 
—  A  specification  of  the  controlled  variable's  initial  value 
—  A  specification  of  the  controlled  variable  function’s  timing  and  value  tolerances 
A  spedfication  of  the  periodic  or  demand  scheduling  parameters 

•  A  complete  specuica  rlon  of  each  mode  class 

•  A  set  of  class  definitions,  including  interface  and  encapsulated  information,  that  is  consistent 
with  the  information  needed  to  complete  the  behavioral  model  for  eadi  dass 

When  you  finish  the  Detailed  Behavior  Spedfication  activity,  you  have  a  complete  description  of  the 
externally  visible  behavior  of  the  software. 

10.2  ENTRANCE  CRITERIA 

lb  perform  Detailed  Behavior  Spedfication,  you  need  the  following  products: 

— 
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•  Monitored  variable  definitions  from  the  dass  interfaces 

•  CcHitrolled  variable  definitions  and  overviews 

•  Ibrm  definitions  from  the  dass  interfaces 

•  Modes  from  mode  dass  interfaces 

•  NAT  relation  information  from  the  information  model,  ^tem  requirements,  and  domain 
knowledge 

•  Dependency  graphs 

•  Timing  and  scheduling  requirements  from  the  ^tem  requirements 

103  AcnvniES 

In  Detailed  Behavior  Spedfication,  you  revisit  and  refine  the  class  definitions.  The  major  focus  of  this 
activiy  is  on  completing  the  detailed  spedfication  of  the  controlled  variable  functions  and  timing 
constraints  and  the  detailed  spedfication  of  the  mode  madiines.  The  subacdvities  are  as  follows: 

•  D^fiM  Controlled  Variable  Bdtavior.  Refine  the  definition  of  each  boundary  dass  thatdcfines 
the  behavior  of  a  controlled  variable.  For  each  controlled  variable,  complete  the  behavioral 
spedfication.  Define  the  value  function,  the  timing  and  tolerance  constraints,  the  scheduling 
parameters,  and  initial  value.  Define  any  relevant  NAT  constraints. 

•  Mode  Classes.  Complete  the  mode  machine  definition  by  defining  the  encapsulated 
information  for  each  mode  class.  Identify  the  events  that  result  in  eadi  mode  transition. 

•  EtfineRarudnit^  Classes.  Comidete  the  definitions  of  the  encapsulated  parts  of  remaining  dasses. 

•  Revisit  Class  Structuring.  Where  completing  the  detailed  definitions  of  the  dasses  requires 
dianging  Class  Structuring  dedsions,  revisit  the  appropriate  Class  Structuring  activify. 

10.4  DEFINE  CONTROLLED  VARIABLE  BEHAVIOR 

The  goal  of  this  activify  is  to  complete  the  detafled  spedfication  of  the  functions  and  timing  constraints 
for  each  controlled  variable.  You  do  this  by  refining  the  definition  of  each  boundary  dass  that  defines 
one  or  more  controlled  variables.  In  Preliminary  Behavior  Specification,  you  identified  the  informa¬ 
tion  needed  to  define  the  controlled  variable  functions.  In  Qass  Structuring,  you  developed  the  dass 
interfaces  to  provide  the  monitored  variables,  modes,  and  terms  needed.  At  this  point,  you  should 
have  suffident  information  to  develop  the  detailed  spedfication  for  each  leaf  dass  defining  a  con¬ 
trolled  variable  independently;  i.e.,  you  can  divide  this  activify  into  separate  work  assignments  for 
each  class.  Thus,  the  following  discussion  is  written  in  terms  of  completing  the  detailed  controlled 
variable  spedfication  for  a  single  dass,  one  variable  at  a  time. 

lb  perform  this  activify,  you  need  the  definitions  of  all  monitored  variables,  modes,  or  terms  on  v^ch 
the  controlled  variable  depends.  Use  the  Controlled  Variable  Overview  from  the  Preliminary  Behav¬ 
ior  Specification  to  identify  these  quantities.  Use  the  dependency  graphs  to  identify  vdiich  dasses 
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provide  needed  information  on  their  interfaces.  The  class  definitions  then  provide  the  detailed 
information  you  can  use  about  each  monitored  variable,  mode,  or  term.  You  will  also  need  any  timing 
constraints  applying  to  the  controlled  variable  from  the  system  requirements  and  any  NAT  constraints 
from  system  requirements  or  other  domain  information. 

The  process  of  com|deting  the  contrdOied  variable  behavior  specification  is  guided  by  the  detaUed  behavk>r 
specification  temfdate  (see  Section  4.4).  You  oomf^ete  the  specification  by  systematically  filUpg  oit  the 
temfdate  where  it  applies  to  the  controlled  variable  being  defined.  This  activity  is  oom|dete  vityta  all  the 
relevant  parts  of  the  temjdate  have  been  filled  out  The  following  sections  provide  guidance  cm  filliitgout 
the  sections  o(  the  controlled  variaUe  form  for  both  periodic  and  demand  controlled  variatdes. 

10.4.1  SPECiiTirnriAL  Value 

In  this  activity,  you  identify  and  define  the  initial  value  that  the  software  must  provide  for  the 
controlled  variable.  You  specify  the  value  by  filling  out  the  Initial  Value  section  as  follows: 

•  Alone.  No  particular  initial  value  is  required. 

•  Value  function.  Initial  value  is  defined  by  the  controlled  variable  function. 

•  iHi  Jal  value  e)qfiresslon  and  Initiating  event.  Use  these  forms  if  the  initial  value  must  be  set 
based  on  a  certain  event  (e.g.,  at  system  generation,  system  initialization,  or  at  run-time)  and 
the  assignment  is  not  covered  1^  the  controlled  varis^le  function. 

-  Initial  value  expression  is  an  expression  giving  the  initial  value  to  be  assigned  to  the 
controlled  variable. 

-  The  Initiating  event  is  the  event  at  which  the  value  must  be  assigned  (e.g.,  system 
initialization). 

10.4.2  Define  Sustaining  CoNDmoNS 

The  sustaining  conditions  give  the  conditions  under  which  the  controlled  variable  function  remains 
defined  after  initialization  (i.e.,  the  conditions  under  which  it  makes  sense  to  evaluate  the  function 
and  set  the  controlled  variable).  For  certain  kinds  of  controlled  variables,  the  entity  being  controlled 
easts  only  if  other  ^tems  are  operating  correctly.  For  instance,  displayed  values  can  be  set  only  as 
long  as  the  display  subsystem  is  operating  properly.  Under  the  sustaining  condition,  you  list  any 
conditions  that  must  be  true  for  the  controlled  variable  to  be  able  to  assume  its  required  values. 

lb  identify  the  sustaining  conditions,  examine  the  quantities  needed  to  define  the  controlled  variable 
fimetions  as  well  as  any  conditions  relevant  to  setting  the  controlled  variable  itself  and  (xeate  the 
sustaining  conditions  as  follows: 

•  Any  undesired  events  that  prohibit  getting  the  values  of  the  monitored  quantities  or  related 
terms 

•  Any  modes  (e.g.,  failure  modes)  in  which  the  function  cannot  be  evaluated  or  the  controlled 
variable  cannot  be  set 
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•  Any  undesired  events  indicating  that  the  ctHitrolled  variable  cannot  be  set 

Where  the  variable  always  has  a  value,  the  sustaining  condition  is  given  the  value  true. 

Examples  The  ^tem  monitors  the  state  of  a  display  and  defines  a  condititm  that  is  true  if  the  display 
has  failed,  called  mon_Dispiay_Faihjfe.  The  controlled  variable  con_Altitude_Display  cannot  be  set 
if  the  disi^y  has  failed  thus,  NOT  mon_Display_Falure  is  a  sustaining  oonditioa 


10.43  SPEcnry  Demand  Behavior 

In  this  activity,  you  create  the  detailed  spedfication  for  a  controlled  variable  with  a  demand  sdieduling 
constraint.  Use  the  controlled  variable  overview  to  determine  the  variable's  sdieduling  constraint. 


10.43.1  Specify  Demand  Ftmctions 

In  this  activity,  you  create  the  function  specifying  the  ideal  value  for  the  controlled  variable.  Demand 
functions  are  characterized  by  the  need  to  respond  to  changes  in  the  environmental  quantities  or 
modes.  Use  an  event  table  to  represent  the  value  function. 

Use  the  table  format  (see  Section  4.2.6.2)  to  guide  creation  of  the  function  and  capture  its 
spedfication.  You  analyze  the  function  to  determine  how  the  behavior  depends  on  the  modes.  You 
create  one  row  of  the  event  table  for  each  set  of  modes  for  whidi  the  behavior  of  the  fimction  is  the 
same. 

Unless  you  have  already  identified  all  of  the  distinct  behaviors,  it  is  easiest  to  begin  by  creating  one 
row  for  each  mode  of  the  relevant  mode  machine.  As  you  begin  to  fill  in  the  rows,  you  can  combine 
any  rows  that  contain  identical  conditions. 

You  oreate  one  column  in  the  table  for  each  distinct  expression  needed  to  define  the  value  of  the 
controlled  variable.  If  the  controlled  variable  is  an  enumerated  type,  create  a  column  for  eadi  distinct 
value.  If  the  controlled  variable  value  is  determined  by  a  set  of  expressions,  create  a  column  for  each 
such  aq>ression.  Put  the  expression  at  the  bottom  of  the  column. 

Example:  In  the  FLMS,  the  controlled  variable  con_Audible_Aiarm  must  be  set;  i.e.,  the  alarm 
must  be  sounded  when  certain  events  occur,  sudi  as  the  fuel  level  going  beyond  safe  limits.  You 
represent  the  function  using  an  event  table  as  shown  in  Ikble  10-1.  You  create  a  row  for  eadi  of 
the  modes  of  the  FLMS  and,  because  con_Audible_AlanTi  is  an  enumerated  type,  one  column  for 
each  possible  value  of  the  variable. 


Visit  eadt  cell  in  the  event  table  row  by  row.  Fbr  a  given  cell,  you  provide  the  event  that  should  cause 
the  controlled  variable  to  take  on  the  corresponding  value  in  the  column  for  the  modes  in  that  row. 
Use  information  about  the  mode  transitions  and  the  assumptions  on  the  mode  class  interface  to  help 
determine  which  events  are  needed.  If  there  is  more  than  one  such  event,  list  each  event  connected 
by  an  OR  operator.  As  you  complete  each  row,  verify  that  only  one  of  the  events  in  that  row  can  occur 
at  any  time  whenever  the  system  is  in  one  of  the  modes  in  that  row. 
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IkUe  10-1.  Event  IkUe  Example  (Incomplete) 


Mode 

Events 

modejC^iating 

mode_Hazard 

mode_Shutdown 

modejibst 

mode_BadLevI>ev 

con_Andible_Afainn 

sound 

silent 

ExMifLB:  Begin  filling  in  the  table,  starting  with  mocie_Operating  (see  Ihble  10-2).  In 
mode_Operating,  the  alarm  must  be  sounded  if  the  fuel  level  goes  out  of  safe  limits  so  the  corre¬ 
sponding  event  is  added  to  the  column  with  the  value  sound.  The  alarm  is  turned  off  (if  it  is  on) 
upon  entry  to  the  mode  so  the  event  ENTERED  is  put  in  the  silent  column.  In  mode_Shutciown, 
the  ^tem  never  changes  the  state  of  the  alarm,  so  an  X  is  entered  in  each  column.  In  mode  test, 
the  stimulating  events  are  based  on  the  time  in  test  The  alarm  is  turned  on  upon  entry  to  test 
mode,  then  turned  off  after  4  seconds.  These  events  are  entered  in  the  table. 


Ibble  10-2.  Event  Ibble  Example  (Completed) 


Mode 

Events 

modejOperating 

X 

mode_Hazard 

ENTERED  OR 

@F(tenn  Fhel  Level  Range  =  withinlimits) 

(glT(teim_Riel_Level_Range  = 
withhilimits) 

mode_Sliutdown 

X 

X 

modejlbst 

@T(tenn_Tfest_'I1me  ^  0  ms) 

@T(tennJIfest_Time  ^  4000  ms) 

mode_BadLevDev 

X 

con_AadiUe_Alarm 

sound 

sflent 

lb  support  readability  of  the  functions,  you  provide  additional  tactual  overview  of  the  spedfied 
behavior  as  necessary.  However,  it  is  the  function  specification  that  represents  the  binding 
requirement  in  case  of  conflict. 

10.4  J.2  Demand  Scheduling  and  Timing  Constraints 

In  this  activity,  you  specify  the  timing  constraints  for  the  controlled  variable  function.  The  timing 
constraints  define  the  range  of  acceptable  behavior  in  time.  Fbr  demand  variables,  this  is  expressed 
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defining  the  interval  over  which  the  software  is  allowed  to  set  the  controlled  variable  following  an 
initiating  event.  You  also  specify  any  NAT  constraints,  such  as  the  minimum  interval  between  events 
of  interest. 

lb  perform  this  activity,  you  use  scheduling  and  timing  information  from  the  system  requirements  as 
well  as  information  about  the  environmental  quantities  from  systems  requirements,  domain  experts, 
hardware  constraints,  and  any  other  sources  describing  the  timing  characteristics  of  the  enviromnen- 
tal  events  that  affect  the  controlled  variable.  You  have  completed  this  activity  when  you  have  filled 
out  all  the  relevant  parts  of  the  timing  and  scheduling  portion  of  the  behavior  spedfication  template 
(Section  4.4). 

The  ability  of  the  software  to  respond  to  every  event  (i.e.,  satisfy  the  ideal  behavior  defined  by  the 
value  function)  may  depend  on  the  timing  characteristics  of  the  initiating  events.  As  part  of  the  NAT 
relation,  you  must  record  any  assumptions  about  how  frequently  initiating  events  can  occur  and  what 
the  minimum  interval  between  occurrences  is.  If  events  can  occur  closely  enough  together  (e.g.  anoth¬ 
er  event  can  occur  before  the  completion  deadline  corresponding  to  the  previous  event),  you  must 
specify  the  tolerance  in  behavior,  ^r  example,  spedfy  whether  the  software  must  respond  to  every 
event  or  is  allowed  to  ignore  events  under  certain  circumstances. 

10.4.4  Specifying  Periodic  Behavior 

In  this  activify,  you  create  the  detailed  spedfication  for  a  controlled  variable  with  a  periodic 
scheduling  constraint.  Use  the  controlled  variable  overview  to  determine  the  variable’s  scheduling 
constraint. 

10.4.4.1  Spedfy  Periodic  Functions 

The  value  function  for  a  controlled  variable  with  a  periodic  timing  constraint  defines  the  values  of  the 
controlled  variable  in  terms  of  the  prevailing  contUtions  when  the  periodic  timing  event  occurs.  Use 
a  condition  table  or  selector  table  (see  Section  4.2.6)  to  guide  creation  of  the  function  and  capture  the 
results. 

Anafyze  the  function  to  determine  how  the  behavior  depends  on  the  modes.  In  particular,  you  must 
determine  each  distind  set  of  modes  where  the  value  of  the  controlled  variable  depends  on  different 
conditions.  You  create  one  row  of  the  condition  table  for  eadi  set  of  mcxles  for  whidi  the  behavior  of  the 
function  is  the  same,  and  enter  the  names  of  the  modes  in  that  row. 

Ejmmple:  The  FLMS  must  provide  status  information  to  a  secondary  status  and  trend  recording 
system.  If  the  fuel  level  is  within  safe  limits,  the  current  fuel  level  is  reported.  If  the  fuel  level  is 
out  of  safe  limits,  a  special  value  indicating  whether  the  level  is  low  or  high  is  provided.  The  status 
information  must  be  provided  every  0.5  second  in  mode_Operating,  mode_Hazard,  and 
mode_ShiJtdown.  It  is  not  provided  in  mode_Test  or  mode_BadLevDev. 

Unless  you  have  already  identified  all  the  distinct  behaviors,  it  is  easiest  to  begin  by  creating  one  row 
for  each  mode  of  the  relevant  mode  madiine.  As  you  begin  to  fill  in  the  rows,  you  can  combine  any 
rows  that  contain  identical  conditions. 

You  create  one  column  in  the  table  for  eadi  distinct  expression  needed  to  define  the  value  of  the 
controlled  variable.  If  the  controlled  variable  is  an  enumerated  type,  o-eate  a  column  for  each  distinct 
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value.  If  the  controlled  variable  value  is  determined  by  a  set  of  expressions,  aeate  a  column  for  each 
such  expression.  Put  the  expression  at  the  bottom  of  the  column. 

Exmiple:  Create  one  row  for  mode_Operating.  mode_Hazard,  and  mode_Shutdown  because 
the  behavior  is  the  same  in  each.  Create  another  row  for  mode_Test  or  mode_BadLevDev. 
Create  a  column  in  the  table  for  each  of  the  possible  values  reported,  the  fuel  level,  low,  and  high 
(see  Tkble  10-3). 


Iklde  10-3.  Initial  Condition  IhUe  Example  (Incomplete) 


Mode 

Condition 

mode_Operating 

mode_E^id 

modejShtttdown 

modejibst 

mode_BadLevDev 

con^Status 

mon_Riel_Level 

low 

high 

Finally,  visit  each  cell  in  the  condition  table  row  by  row.  Fill  each  cell  with  a  condition  that  must  hold 
in  the  mode  defined  by  the  row  for  the  /ariable  to  be  assigned  the  value  at  the  bottom  of  the  column. 
As  you  complete  each  row,  verify  that  exactly  one  of  the  conditions  in  a  row  must  be  true  whenever 
the  system  is  in  one  of  the  modes  in  that  row. 

Example;  For  mode_Operating,  mode^Hazard,  and  mode_Shutdown,  the  controlled  variable 
is  determined  by  the  value  of  mon_Fuel_Lewl  if  the  fuel  level  is  within  range.  Thus,  you  fill  the 
corresponding  cell  with  the  condition  term_Fuel_Level_Range  =  withinlimits.  The  remaining 
cells  in  the  row  correspond  to  the  level  being  low  or  high.  The  function  is  not  defined  in  modeJTest 
or  mode_BadLevDev,  so  place  an  X  in  these  cells  (see  Tkble  10-4). 


Tkble  10-4.  Condition  TkUe  Example  (Completed) 


Mode 

Condition 

mode_Pperating 

mode_Hazard 

mode_Shutdown 

tenn_ 

Fuel_Level_Range  = 
withinlimits 

tenn_ 

Fhel_Level_Range  = 
levellow 

term_ 

Fhel_Level_Range  = 
levelhigh 

modeJTest 

X 

X 

X 

mode_BadLevDev 

con_Status 

mon_Fuel_Level 

low 

high 

The  condition  table  is  easier  to  check  if  you  use  conditions  whose  consistency  is  obvious  from  their 
very  form.  For  example,  conditions  of  the  form  A  and  NOT  A  clearly  exclude  one  another  and  add  up 
to  true. 


10-7 


1(X  Detailed  Bchurior  Spedficaiioo 


10.4A.2  Specify  Periodic  Scheduling  and  Timing 

In  this  activity,  you  specify  the  scheduling  and  timing  constraints  for  a  periodic  controlled  variable 
function.  lb  perform  this  activity,  you  use  scheduling  and  timing  information  from  the  system  specifi¬ 
cation  as  well  as  information  about  the  environmental  quantities  from  systems  specifications,  domain 
experts,  hardware  constraints,  and  any  other  sources  describing  the  controlled  variable’s  periodic  tim¬ 
ing  constraints  .  You  have  completed  this  activity  when  you  have  filled  out  all  the  relevant  parts  of  the 
timing  and  scheduling  portion  of  the  behavior  specification  template  (Section  4.4).  Use  the  timing  and 
scheduling  portions  of  the  template  to  guide  identification  of  the  timing  and  scheduling  quantities. 

Fbr  a  periodically  produced  value,  use  the  initiation  delay  and  completion  deadline  to  express  the 
allowed  variation  between  the  exact  interval  given  by  the  period  and  when  the  controlled  variable’s 
value  may  be  changed.  In  general,  there  will  be  a  range  of  times  in  a  period  that  is  acceptable;  this 
range  is  expressed  by  giving  the  initiation  delay  and  completion  deadline. 

Examples  If  you  give  a  period  of  500  milliseconds,  an  initiation  delay  of  SO  milliseconds,  and  a 
completion  deadline  of  400  milliseconds,  then  the  software  is  required  to  update  the  controlled 
variable  in  the  interval  between  50  and  400  milliseconds  after  the  start  of  the  500-millisecond 
period. 

Some  variables  with  periodic  constraints  are  set  only  under  certain  conditions.  For  example,  where 
the  user  chooses  what  is  currently  displayed  on  a  so^een,  the  system  only  needs  to  update  the  displayed 
values.  If  this  information  is  not  captured  in  the  modes,  use  the  initiation  and  termination  section  to 
define  when  the  values  of  the  controlled  variable  need  to  be  updated  and  when  they  do  not.  Do  this 
by  giving  the  event  that  signals  when  the  value  must  be  provided  (initiating  event)  followed  Ify  the 
event  that  signals  when  the  event  no  longer  needs  to  be  provided  (terminating  event).  If  the  initiation 
and  termination  events  depend  on  the  mode,  then  use  an  event  table  to  specify  the  initiation  and 
termination  events  for  each  mode. 

Examples  con_Status  is  only  required  to  be  updated  in  mode_Operating,  mode_Hazard,  and 
mode_Shutdown  but  is  not  updated  in  mode_Test  or  mode_BadLevDev.  Provide  an  event  table 
as  shown  in  Ihble  10-5. 


llible  10-S.  Initiation  and  Termination  Events  for  con  Status 


Mode 

Event 

mode_Operating  mode_Haz3rd 

ENTERED 

X 

mode_Shatdown 

modeJTest  mode_BadLevDev 

X 

ENTERED 

Initiation  and  Termination 

Initiation 

Ibnnination 

Where  the  initiation  and  termination  events  are  provided,  the  requirement  is  that  the  value  be 
periodically  updated  between  the  initiating  event  and  the  terminating  event  at  the  spedfied  interval. 
If  the  process  continuously  runs,  you  only  provide  the  initiating  event  (e.g.,  system  initialization). 
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10.4.5  Specify  Tolerance  Constraints 

In  this  activity,  you  determine  and  specify  the  allowed  deviation  from  the  controlled  variable’s  ideal 
value  (as  expressed  by  the  value  function).  You  perform  this  activity  only  for  variables  that  model  con¬ 
tinuous  quantities  (e.g.,  degrees  of  angle)  or  otherwise  have  a  notion  of  more  and  less  accurate  values. 
You  do  not  express  tolerance  for  variables  that  have  only  one  ideal  value  (e.g..  Boolean  or  enumerated 
types).  Because  the  acceptable  tolerance  is  expressed  in  terms  of  the  controlled  variable’s  value  (i.e., 
the  externally  visible  quantify  affected  by  the  fystem  including  the  output  devices),  you  must 
determine  the  allowed  tolerance  based  on  the  originating  system  requirements. 

You  specify  the  tolerance  by  defining  a  function  that  maps  the  system  state  to  the  corresponding 
allowed  deviation  fir om  the  ideal.  In  most  cases,  this  function  is  a  constant;  i.e.,  the  controlled  variable 
must  be  set  with  the  same  tolerance  at  all  times.  Where  the  required  tolerance  is  a  constant,  it  is 
sufficient  to  specify  the  error  bound  on  the  controlled  variable  v^ue. 

Example-.  FLMS  system  requirements  dictate  that  the  fuel  level  must  be  displayed  within  0.5  on 
of  the  actual  value.  Thus,  the  controlled  variable  con_Level_Display  has  a  constant  tolerance 
function  with  the  value  ±  0.5  cm  of  the  ideal  value. 

Where  the  required  tolerance  is  not  a  constant,  otpress  the  tolerance  as  a  function  of  the  relevant 
monitored  variables,  terms,  or  modes,  as  necessary.  If  the  tolerance  is  a  direct  function  of  the  moni¬ 
tored  variables,  write  the  expression.  If  the  tolerance  is  a  function  only  of  the  modes,  use  a  selector 
table.  If  the  tolerance  is  a  function  of  modes  and  conditions,  use  a  condition  table.  Look  for  tolerance 
to  vary  with  the  mode  under  the  following  drcumstances: 

•  Value-Dependent  Variation.  The  required  tolerance  may  vary  depending  on  changes  in  value  of 
the  quantities  being  monitored  or  controlled.  In  particular,  less  tolerance  may  be  required  as 
a  measured  quantify  increases  in  value. 

Example;  The  displayed  altitude  of  an  aircraft  is  a  controlled  variable.  The  required 
tolerance  depends  on  height:  the  greater  the  altitude,  the  less  tolerance  is  needed.  You  are 
required  to  provide  the  altitude  within  2  feet  below  500  feet  of  altitude,  within  10  feet  from 
500  to  5,000  feet  of  altitude,  and  within  50  feet  above  5,000  feet  of  altitude. 

•  Degraded  Modes  of  Operation.  Systems  frequently  have  degraded  modes  of  operation.  Less 
tolerance  may  be  required  in  a  degraded  mode  than  a  normal  operating  mode.  In  such  a  case, 
the  required  tolerance  should  be  expressed  as  a  function  of  the  mode. 

•  VaryingLoad.  The  required  tolerance  may  vary  in  proportion  to  the  system  load.  This  can  occur 
when  there  are  fixed  computing  resources  but  a  varying  load  at  run  time  (e.g.,  where  a  system 
must  track  a  set  of  targets).  In  some  cases,  you  must  trade  tolerance  for  the  ability  to  handle 
an  increased  load;  e.g.,  the  system  tracks  more  targets  with  less  tolerance.  In  such  cases,  the 
tolerance  should  be  expressed  as  a  function  of  the  system  loading  (e.g.,  number  of  targets 
tracked). 

10.5  REFINE  MODE  CLASSES 

In  this  activity,  you  complete  the  definition  of  the  mode  classes  by  completing  the  specification  of  the 
mode  machines.  Tb  perform  this  activity,  you  need  the  initial  mode  class  definitions  you  created  in 
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Class  Structuring,  including  the  modes  and  transitions.  You  also  need  the  dehnitions  of  any  monitored 
variables  or  events  that  the  mode  class  depends  on. 

Complete  the  definition  of  a  mode  class  by  defining  all  of  the  transition  events  that  cause  mode 
changes  and  any  auxiliary  terms  needed  in  the  class’s  encapsulated  information.  Use  the  dependent^ 
graph  for  the  mode  class  to  locate  the  definitions  of  the  terms  and  events  on  which  the  mode  machine 
depends.  Use  the  mode  transition  graph  or  mode  transition  table  to  help  ensure  that  you  have 
identified  all  of  the  necessary  events. 

10.6  REHNE  REMAINING  CLASSES 

In  this  activity,  you  complete  the  definitions  of  the  encapsulated  parts  of  the  boundary  and  term  classes 
except  the  specification  of  the  the  input  and  output  variables  and  the  IN  and  OUT  relations,  lb  per¬ 
form  this  activity,  you  need  the  class  specifications  developed  in  the  Class  Structuring  activity.  In  this 
activity,  you  do  the  following: 

•  Provide  or  complete  the  definitions  of  any  encapsulated  terms  required  to  support  the  class 
interface  definitions. 

•  Provide  or  complete  the  definitions  of  any  encapsulated  constants  needed  to  support  the  class 
interface  definitions. 

•  Provide  overview  and  explanatory  material  as  needed. 

You  have  completed  this  activity  when  you  have  defined  all  of  the  encapsulated  parts  of  each  class 
specification  except  the  input  and  output  variables  and  the  IN  and  OUT  relations. 

10.7  REVISIT  CLASS  STRUCTURING 

Throughout  the  Detailed  Behavior  Specification,  you  revisit  decisions  you  made  in  Class  Structuring. 
You  develop  the  Detailed  Behavior  Specification  working  from  the  boundary  classes  that  define  the 
controlled  variables  back  to  the  classes  that  define  the  monitored  variables  in  the  controlled  variable 
function  domain.  You  begin  by  developing  the  encapsulated  information  of  a  boundary  class  that  de¬ 
fines  a  controlled  variable.  The  detailed  specifications  for  different  classes  may  be  developed 
independently. 

As  you  develop  the  Detailed  Behavior  Spedfication,  you  may  determine  that  you  need  terms, 
monitored  variables,  or  possibly  modes  that  are  not  currently  provided  by  other  classes.  In  such  cases, 
you  either  define  the  needed  information  in  the  class  you  are  specifying  or  you  need  to  revisit  the  Class 
Structuring  activity  as  follows: 

•  Where  a  new  monitored  variable  or  term  must  be  provided,  determine  whether  the  definition 
should  be  created  locally  or  provided  by  another  class.  The  variable  or  term  should  be  pro¬ 
vided  by  another  class  if  its  definition  requires  the  information  encapsulated  by  that  class  or 
is  part  of  the  abstraction  provided  by  that  class.  Create  a  new  term  class  or  boundary  class  if 
necessary  to  address  the  Class  Structuring  aiteria. 

•  Where  a  monitored  variable  or  term  must  be  changed,  you  must  coordinate  the  change  with 
any  other  classes  that  use  the  variable  or  term.  Use  the  dependency  graph  to  determine  which 
class  definitions  may  be  affected. 
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•  Where  a  mode  definition  must  be  added  or  changed,  you  must  revisit  all  of  the  dasses  using  the 
mode  class.  Use  the  dependency  graph  to  determine  which  class  definitions  may  be  affected. 

As  you  revisit  the  Class  Structuring  activity,  record  any  changes  in  classes  and  class  dependendes  in 
the  affected  dependency  graph.  When  you  have  completed  this  activity,  you  should  have  a  set  of 
dependency  graphs  that  is  consistent  with  the  information  provided  and  used  by  each  class. 

10.8  EVALUATION  CRITERU 

When  the  Detailed  Behavior  Spedfication  is  complete,  the  required  behavior  specification  for  every 
controlled  variable  should  be  complete  and  consistent.  The  following  sections  discuss  CoRE’s 
evaluation  criteria  for  a  single  controlled  variable. 

10.8.1  Completeness 

For  controlled  variable  functions,  there  is  a  well-defined  notion  of  completeness.  A  function  is 
complete  when  every  value  in  the  domain  is  mapped  to  some  value  in  the  range.  For  CoRE  functions, 
this  means  that  every  possible  value  of  the  relevant  monitored  variables  must  be  mapped  to  some  val¬ 
ue  of  the  controlled  variables.  Thus,  you  assess  completeness  by  ensuring  that  this  property  holds  for 
each  of  the  functions  spedfying  the  controlled  variable  behavior  (value  function,  tolerance,  and 
timing): 

•  Imdal  Value.  If  you  supplied  a  value  function,  the  value  function  assigns  a  value  on  entering 
the  initial  system  mode.  Otherwise,  an  initiating  event  and  initial  value  must  be  given. 

•  Mode  Class.  If  the  initial  value  is  none,  the  controlled  variable  functions  should  be  the  same 
for  all  system  modes.  If  one  or  more  modes  are  spedfied,  the  controlled  variable  functions 
should  be  defined  for  all  of  the  listed  mode  machines. 

•  Sustaining  Conditions.  The  sustaining  conditions  must  give  a  set  of  conditions  or  true. 

•  Value  Fhnction.  The  function  is  complete  if  it  defines  the  behavior  over  all  the  possible  values 
of  the  function’s  domain.  If  the  controlled  variable  is  a  function  only  of  the  monitored  vari¬ 
ables,  ensure  that  the  function  is  spedfied  for  all  the  possible  values  of  those  variables.  If  it 
is  a  function  of  a  particular  mode  class,  ensure  that  the  function  covers  every  mode  of  the  rele¬ 
vant  mode  class.  Section  4.2.6  describes  the  inspection  procedure  you  should  follow  for  each 
type  of  table  (i.e.,  condition,  event,  or  selector). 

For  an  enumerated  type  of  controlled  variable,  the  columns  should  cover  every  possible 
enumerated  value  or  there  should  be  a  statement  that  the  values  are  never  used.  For  continu¬ 
ous  valued  controlled  variables,  the  columns  should  cover  the  range  of  the  variable  (e.g.,  x<0, 
x=0,  x>0)  or  there  should  be  a  statement  spedfying  which  ranges  are  never  used. 

Example:  The  function  for  the  controlled  variable  con_Low_Alarm  is  defined  in  terms  of  the 
mode  class  class  Jn_Operation.  You  verify  that  every  mode  of  the  mode  machine  appears  in 
some  row  of  the  event  table  defining  the  value  function.  You  verify  that  every  possible  value 
of  LowAlarm  appears  in  a  column  of  the  event  table. 

•  Timing  and  Scheduling  Requirements.  Verify  that  each  relevant  part  of  the  timing  and  scheduling 
template  is  filled  out. 
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10^^  Consistency 

A{^ly  the  following  consistency  checks  to  the  specification  of  REQ: 

•  Value  function.  Check  that  the  controlled  variable’s  value  function  specifies  exactly  one 
required  behavior  for  each  state  of  the  system. 

-  Event  Table.  An  event  table  desaibes  consistent  behavior  if  the  same  event  does  not 
assign  two  different  values  to  the  controlled  variable.  You  must  check  that  the  events 
in  a  given  row  of  the  table  are  not  the  same  and  do  not  imply  one  another  (i.e.,  the 
events  are  defined  so  that  the  cxxnirrence  of  one  means  that  the  other  also  occurs).  You 
must  also  check  that  events  in  different  columns  cannot  occur  simultaneously  or,  if 
they  can,  that  the  specification  states  whidi  colunm  value  applies. 

-  Condition  Table.  A  condition  table  is  consistent  if  the  conditions  in  a  given  row  of  the 
table  are  mutually  exclusive  and  the  disjunction  (i.e.,  all  conditions  joined  by  OR  oper¬ 
ators)  is  true.  The  conditions  are  mutually  exclusive  if  only  one  of  the  conations  in  a 
row  can  be  true  at  a  given  time;  e.g.,  the  conditions  LevelLow  and  NOT  LevelLow  nec¬ 
essarily  exclude  one  another.  The  conditions  add  up  to  true  if  one  of  the  conditions  in 
the  row  must  be  true  at  a  given  time;  e.g.,  one  of  the  conditions  LevelLow  or  NOT 
LevelLow  must  be  true. 

•  Tolerance  Function.  Check  that  the  function  assigns  a  tolerance  for  every  state  for  which  the 
value  function  assigns  a  value.  You  must  also  check  that  the  expressions  do  not  assign  two  pos¬ 
sible  accuracies  to  the  same  state  (i.e.,  the  expressions  are  indeed  a  mathematical  function). 
If  event  or  condition  tables  are  used,  appfy  the  same  checks  that  are  desoibed  for  the  value 
function. 

•  Timing  Constraints.  Check  that  the  timing  and  scheduling  constraints  satisfy  the  properties 
defined  in  Section  4.3. 

10.9  EXIT  CRITERIA 

Detailed  Behavior  Specification  is  complete  when  the  required  behavior  for  every  controlled  variable 

is  completely  defined. 


11.  DEFINE  HARDWARE  INTERFACE 


The  previous  activities  described  the  required  behavior  of  the  software  in  terms  of  monitored  and 
controlled  variables.  In  the  Define  Hardware  Interface  activity,  you  describe  the  resources  and  the 
input  and  output  variables  available  to  the  software  to  get  the  vdues  of  monitored  variables  and  to 
set  the  value  of  controlled  variables,  respectively. 

11.1  GOALS 

The  goal  of  the  Define  Hardware  Interface  activiQr  is  to  complete  detailed  specification  of  the 
boundary  classes  by  defining  the  input  and  output  variables  and  the  IN  and  OUT  relations.  The 
hardware  interface  specification  defines  the  resources  the  software  may  use  and  serves  as  a 
demonstration  that  it  is  feasible  to  get  the  monitored  values  and  set  the  controlled  ones.  Where  the 
use  of  particular  inputs  or  outputs  represents  requirements,  this  should  be  stated  explidtly  and  the 
appropriate  traceability  specified.  The  goals  of  identifying  the  variables  and  relations  are  as  follows: 

•  hi  defining  the  input  variables,  you  explidtly  identify  the  input  resources  available  to  the 
software  to  determine  the  values  of  the  monitored  variables. 

«  In  defining  the  output  variables,  you  e3q>lidtly  identify  the  output  resources  available  to  the 
software  to  affect  the  values  of  the  controlled  variables. 

The  IN  relation  defines  the  relationship  between  the  monitored  variables  and  the  input  variables. 
Siihilarfy,  the  OUT  relation  defines  the  relationship  between  the  output  variables  and  foe  controlled 
variables.  In  defining  these  relationships,  you  have  foe  following  go^s: 

•  The  spedfication  of  each  monitored  variable  defines  a  range  of  values  over  vfoidi  foe  software 
must  be  able  to  measure  foe  monitored  quantity  and  a  precision  that  e]q)resses  how  accurately 
foe  quantity  must  be  measured.  The  goal  of  foe  IN  relation  specification  is  to  show  that  foe 
inputs  are  sufBdent  to  measure  the  monitored  variables  ao-oss  foe  required  range  and  to  foe 
required  predsion. 

•  The  spedfication  of  each  controlled  variable  defines  a  range  of  values  over  whidi  foe  software 
must  be  able  to  set  foe  controlled  quantify  and  a  predsion  that  expresses  how  accurately  foe 
quantify  must  be  set.  The  goal  of  foe  OUT  relation  spedfication  is  to  show  that  foe  outputs 
are  sufiSdent  to  set  foe  controlled  variables  across  foe  required  range  and  to  foe  required 
precision. 

A  final  goal  is  to  spedfy  for  foe  subsequent  designers  and  implementers  how  foe  hardware  resources 
are  used  to  get  foe  monitored  variables  or  set  the  controlled  variables.  This  includes  foe  device 
protocols,  timing  characteristics,  and  data  conversion  if  necessary. 
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112  ENTRANCE  CRITERIA 

For  the  Define  Hardware  Interface  activity,  you  need  the  following  products  from  previous  activities: 

•  Boundaiy  class  deflnitions 

•  Input  and  output  device  interface  specifications  from  system  requirements 

113  ACTIVITIES 

The  Define  Hardware  Interface  activity  is  composed  of  the  following  subactivities: 

•  Assign  Inf  .  and  Output  Variables  to  Boundary  Classes 

•  Define  Input  and  Output  Variables 

•  Define  IN  and  OUT  Relations 

113.1  Assign  Input  and  Output  Variables  to  Boundarv  Classes 

Allocate  the  definitions  of  the  input  and  output  variables  to  the  same  class  that  encapsulates  the 
corresponding  environmental  variable.  Examine  the  environmental  variables  that  you  have  defined.  For 
each  monitored  variable,  dedde  vdiidi  input  variables  die  software  can  use  to  determine  the  variable’s 
value.  R)r  eadi  controlled  variable,  dedds  vdiich  output  variables  the  software  can  use  to  set  its  value. 
Encapsulate  the  variable  in  the  class  that  contains  the  definition  of  the  environmental  variable. 

Because  the  boundaiy  class  that  contains  the  monitored  variables  also  encapsulates  all  the  input  variables 
that  can  determine  the  values  of  the  monitored  variables,  the  class  encapsulates  the  IN  relation  for  the 
input  variables.  Define  the  IN  relation  as  part  of  the  encapsulated  information  of  the  class.  Similarly,  de¬ 
fine  the  OUT  relation  as  part  of  the  encapsulated  information  for  the  dass  defining  the  corresponding 
output 

If  die  software  uses  the  variable  to  access  environmental  variables  defined  in  different  dasses,  reassess 
die  decision  to  assign  the  environmental  variables  to  different  boundaiy  dasses.  You  may  dedde  that  the 
environmental  variables  should  be  assigned  to  die  same  dass. 

1133  Define  Input  AND  Output  Variables 

In  the  Define  Input  and  Output  Variables  activity,  you  spedfy  the  detailed  characteristics  of  the  input 
and  output  variables  and  describe  how  they  are  accessed  by  the  software.  Identify  the  input  and  output 
variables  by  denoting  each  resource  that  independently  changes  value  (Heninger  1980)  by  a  variable. 

Create  the  variable  spedfication  by  filling  out  the  applicable  parts  of  the  input  and  output  variable 
template  as  shown  in  Ihble  11-1.  First,  provide  a  unique  name  for  each  variable.  Users  of  the  require¬ 
ments  need  to  know  with  what  hardware  the  variable  is  assodated,  how  to  read  or  write  the  variable, 
the  values  that  they  can  read  or  write,  and  the  representation  of  the  values  that  the  variable  assumes 
(typically  a  bit  pattern).  Ihble  11-2  is  a  sample  definition  of  a  numeric  input  variable  from  the  FLMS. 
The  abstract  values  of  the  input  variable  ln_Diff_Press  are  integers  in  the  range  0  to  255.  An  8-bit  un¬ 
signed  integer  represents  the  values.  Ihble  11-3  isa  sample  definition  of  a  nonnumeric  output  variable. 
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The  abstract  values  of  out_Shutdown  are  true  and  false.  Zero  in  bit  1  of  the  byte  represents  true.  One 
in  bit  1  represents  false. 


Ikble  11-1.  Input  and  Output  ^^riaUe  Template 


Input  and  Output  triable 

Definition 

Acronym 

Unique  identifier  for  the  variaUe 

Hardware 

The  hardware  unit  with  \diidi  the  variable  is 
associated 

\UUC8 

The  abstract  values  you  can  read  or  write: 

•  Nomeric.  Specify  range  and  resolution  of 
numeric  variables. 

•  Nonnnmerie.  List  the  abstract  values  of 
nonnumeric  variaUes. 

Data  TWinsftr 

How  to  read  or  write  the  variable 

Data  Representation 

How  the  variaUe  assumes  the  abstract  values  are 
represented 

Ikble  11-2.  Sample  Definition  of  Input  Variable  Diff_Press 


Acronym 

in_Diff_Press 

Hardware 

Differential  Pressure  Unit 

Values 

[0.255] 

Data  Ihinsfer 

ADqo) 

Data  Representation 

8-bit  unsigned  integer 

Ikble  11-3.  Sample  Definition  of  Output  'triable  Shutdown  Signal 


Acronym 

oot_Shutdown 

Hardware 

Pump  Shutdown  Relay 

Values 

False  (lb) 

Thie  (Ob) 

Data  Iknnsfer 

Porte 

Data  Representation 

Bit  1  of  byte 

The  information  you  need  to  complete  the  variable’s  definitions  should  come  from  the  input  and 
output  interface  specifications.  You  often  will  have  to  manipulate  the  information  to  obtain  a  form 
suitable  for  comfdeting  the  variable  definition.  If  the  information  that  you  need  to  complete  the 
definition  is  not  included  in  the  input  and  output  interface  specifications,  you  may  have  to  interview 
the  engineers  who  designed  the  input  and  output  interfiice  or  experiment  with  the  hardware. 

1U3  Desine  in  and  OUT  Relations 

Hie  goal  of  this  activiQ'  is  to  define  the  relationship  between  the  monitored  and  controlled  variables 
and  the  input  and  output  variables,  respectively.  M  part  of  spedfying  this  relationship,  you  establish 


11-3 


11.  DcBm  Hardwira  Imerboe 


that  the  input  variables  are  sufficient  to  measure  the  monitored  quantities  and  that  the  outputs  are 
sufficient  to  set  the  controlled  quantities.  Fbr  numeric  quantities,  you  also  define  the  conversimi. 

1133.1  Define  IN  for  a  Monitored  Variable 

Define  an  IN  relation  for  each  monitored  variable.  You  define  the  relation  to  siu>w  that  the  software 
can  determine  the  value  of  the  monitored  variable,  using  the  available  inimts,  to  that  variable’s  range 
and  precision  requirements. 

Use  the  monitored  variable’s  definition  to  determine  the  range  of  values  and  precision.  Demonstrate 
that  the  available  inputs  meet  the  monitored  variable’s  range  requirements  1^  giving  a  mapi^  from 
the  range  of  the  monitored  variable  to  the  corresponding  inputs.  Fbr  discrete  monitored  variables 
(e.g..  Boolean  or  enumerated  types),  this  requires  showing  the  exact  mapping  between  values.  For 
continuous  quantities  (e.g.,  degrees,  feet),  show  the  majq^  over  the  range  of  values. 

For  continuous  quantities,  it  is  usually  ea»er  to  describe  the  expected  value,  error,  and  delay 
separately.  In  this  case,  you  define  its  expected  value  as  a  funcdmiof  the  values  of  monitored  variables. 
You  then  give  the  minimum  accuracy  and  maximum  delay  associated  with  the  input  device. 

Hgure  11-1  illustrates  an  example  of  an  IN  relation  for  the  input  in_Diff_Press.  in_Dlff_Press  is  used 
to  get  the  value  of  the  monitored  variable  mon_Fuel_LeveI. 

The  foDowing  table  describes  how  inJDiffJPress  re&ects  the  value  of  mon_Riel_Levd.  The  device 
is  calibrated  so  that  it  has  a  value  in  the  range  [1.2S4]  vhen  monJPbelJLevel  is  between  13.0  cm 
(const JUCB)  and  27.0  cm  (oonst_UCS).  A  value  of  0  for  inJDiffJPress  indicates  that 
mon_F]el JLevd  has  fallen  below  the  lower  calibration  bound  (GODst_LCB)  or  that  the  device  has 
fafled.  A  value  of  2S5  indicates  that  mon_Fhel_Level  has  risen  above  the  iq>per  calibratk>n  bound 
(oonst_UCB)  or  that  the  device  has  failed. 

Determining  the  Value  of  in  J!>iff_Press 


WiriaUe 

Ibkrance 

Delay 

in_Diff_Press 

0.1  on 

03s 

Condition 

mon  Fhel  Level 

const  LCB  <  mon  Fhel  Level  <  const  UCB 

mon  Fuel  Level  > 

<  const  JLG3 

const_UCB 

mJDiff_Press  =  0 

inJWff_Press  in  [1 ..  254] 

in_Diff_Press  =  255 

The  table  describes  how  in_Diff_Press  reflects  the  value  of  mon_FUel_Level_Unknown.  When 
in_Diff_PFess  has  a  value  of  either  0  or  2S5,  we  assume  that  in_Diff_Press  has  failed  and  that 
the  FLMS  is  unable  to  determine  the  value  of  mon_Fhel JLeveL 

The  following  e:q)iession  describes  how  the  value  of  mon^FhelJLevel  can  be  calculated  from 
the  value  of  inJDi£f_Press: 

„  ,  in  Diff  Press-1  , 

mon_FHel_Level  =  — = — === - x  (oonst_UCB  -  const_LCB)  +  const_LCB  ±  0.28  cm 


Hgure  11-1.  ]NRelatiooform_Diff_Fress 
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After  you  have  defined  the  mapping  from  the  range  of  the  monitored  variable  to  the  inputs,  you  can 
define  the  conversion.  The  expression  following  the  table  defines  the  conversion  from  the  values  (rf 
in_Diff_Press  to  the  values  of  mon_Fuel_Level.  The  specification  of  in_Diff_Press  is  oomfdeted  by 
specifying  the  delay  associated  with  getting  the  inputs  and  the  accuracy  relative  to  the  monitored 
quantify.  The  specification  for  in_Diff_Press  is  given  in  Figure  11-2. 


The  input  variaUe  ui_Diff_Press  has  a  precision  of 

const_UCB  -  const_LCB  27.0  -  13.0  «  „ 

- - - 254 -  0Q551cm 

which  is  sufficient  to  represent  nion_FUel_L6vel  to  the  required  OJ  cm.  The  maximum  error 
introduced  by  the  delay  of  0.2  s  is 

0.2  s  X  const_Max_Fuel_Rate  «■  0.2s  X  0J75cm/s  -  0.075cm 

The  maximum  error  introduced  by  the  device  error  and  delay  of  in_Diff_Press  is  the  sum  of 
the  two,  0.175  cm,  which  satisfies  the  needs  of  the  FU^  to  determine  the  value  of 
mon  Fhel  Level  to  03  cm. 

*  »  _  -  _  _  ■ 

Rgurell-2.  AKuracySpecificatioQform_Diff_Flreas 

113,3,2  Define  OUT  for  a  Controlled  Variable 

Define  an  OUT  relation  for  each  controlled  variable.  You  define  OUT  to  show  that  the  software  can 
set  the  values  of  the  controlled  variable,  using  rite  available  outputs,  to  that  variable’s  range  and 
precision  requirements. 

Use  the  controlled  variable’s  definition  to  determine  the  range  of  values  and  predsion.  Demonstrate 
that  the  available  outputs  meet  the  controlled  variable’s  value  requirements  by  giving  a  mailing  firom 
the  set  of  possible  outputs  to  the  set  of  possible  controlled  variable  values.  For  discrete  controlled  vari¬ 
ables  (e.g..  Boolean  or  enumerated  fypes),  this  requires  showing  the  exact  mapping  between  values. 
For  continuous  quantities  (e.g.,  angle  of  a  flap,  degrees  of  rotation  of  a  dial),  show  the  mapping  over 
the  range  of  values. 

For  continuous  quantified  it  is  usually  easier  to  describe  the  opected  value,  error,  and  delay 
separately.  In  this  case,  you  define  its  «q)ected  value  of  the  controlled  variable  as  a  function  of  the 
output  values.  You  then  give  the  minimum  accuracy  and  maximum  delay  assodated  with  the  output 
devices. 

Any  of  the  CoRE  notations  can  be  used  to  define  the  OUT  relation.  If  the  controlled  variable  is  a 
continuous  function  of  the  output  variables,  use  standard  mathematical  notation.  If  the  controlled 
variable  depends  on  conditions  or  modes,  use  the  condition  or  event  tables  desoibed  in  Section  4.1.6. 

Ihble  11-4  illustrates  the  use  of  a  condition  table  to  spedfy  the  mapping  from  the  ouq>ut  variable 
out_Shutdown  to  the  values  of  the  Boolean  controlled  variable  Shutdown_Relay.  Because  the  values 
are  diso'ete,  the  table  gives  the  maj^^  for  each  value;  this  shows  that  the  available  output  values 
cover  the  range  of  the  controlled  variable.  The  table  gives  the  e]q)ected  value  of  the  control!^  variable 
con_Shutdown_Relay  as  a  function  of  the  output  variable  out^Shutdown.  The  first  column  of  the 
table  indicates  that  ifffie  output  variable  out_Shutdown  =  true,ffiencon_Shutdown_Relay  =  open. 
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The  second  column  of  the  table  specifies  that  if  out^Shutdown  » false,  then  con_Shutdown_Relay 
is  set  to  closed. 


Tkble  11-4.  Sample  OUT  Relation  for  Controlled  Variable  oon_Shutdown_Relay 


1  CoBditioB 

out_Shutdown  » true 

oot_Shutdown  «  false 

oon_Shutdown_ReIay  -  <^n 

oonjShntdownJRelay  «  dosed 

After  you  have  spedfied  the  eapected  value  of  the  controlled  variable  as  a  function  of  the  output 
variables,  define  the  error  and  delay  introduced  by  the  ouQnit  devices.  Discrete  values  have  no 
associated  error.  For  continuous  values,  these  are  tyjHcally  constants.  Ikble  11-5  indicates  that  if  the 
software  sets  the  value  of  the  output  variable  out^Sfiutdown  to  true,  for  examide,  then  the  amtrolled 
variable  con_Shutdown_Reiay  must  assume  the  value  open  within  10  milliseconds.  Because 
Shutdown_Relay  is  an  enumerated  variable,  there  is  no  tolerance  associated  with  it  (indicated  by  NA 
in  the  table). 

Tkble  11-S.  Sample  Tolerance  and  Delay  for  Controlled  Variable  oonjShutdown_Relay 


Error 

NA 

Delay 

10  ms 

For  continuous  values,  you  should  also  specify  the  conversion  from  the  output  to  the  values  of  the 
controlled  variable. 

Eadi  controlled  variable’s  REQ  relation  defines  an  associated  tolerance  in  value  and  time.  You  must 
show  that  the  outputs  can  be  set  with  sufficient  accuracy  to  satisfy  the  tolerance  in  value.  You  must 
show  that  the  maximum  delay  in  setting  the  values  is  less  than  the  delay  allowed  by  the  REQ  relation. 

11.4  EVALUATION  CRITERU 

This  section  describes  how  to  evaliiate  the  consistency  and  completeness  of  the  hardware  interface 
that  you  have  defined.  You  should  be  able  to  answer  ^es”  to  eadi  of  the  questions  listed  below: 

•  For  each  of  the  input  and  output  variables  that  you  have  identified: 

-  Is  the  variable  template  filled  in? 

•  For  each  of  the  input  variables  that  you  have  defined: 

-  Is  there  at  least  one  IN  relation? 

-  Are  all  of  the  monitored  variables  in  the  donutin  of  IN  defined  in  the  class? 

•  For  eadi  of  the  controlled  variables  that  you  have  defined: 

-  Is  there  at  least  one  OUT  relation? 

-  Are  all  of  the  output  variables  in  the  domain  of  OUT  encapsulated  by  the  boundary 
dass? 
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•  Can  each  output  variable  be  used  to  set  the  value  of  at  least  one  controlled  variable? 

•  Can  the  value  of  each  monitored  variable  be  determined  from  the  IN  relation? 

11^  EXrrCRlTERlA 

Define  Hardware  friteifiaoe  is  oonqilete  when  you  can  answer  “ytsT  to  all  of  the  questions  Ifrted  in 
Sedk»11.4. 


11.  DcSm  Htfdwm  bMHfMe 
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12.  ANALYZING  A  CoRE  SPECIFICATION 


Core’s  models,  the  use  of  mathematics,  and  the  use  of  formats  for  capturing  requirements  all  support 
analysis  of  a  CoRE  specification  for  completeness  and  consistent^.  I>etailed  procedures  for  analyzing 
the  products  of  individual  activities  have  been  provided  in  the  detailed  process  sections  (Sections  8 
through  11).  This  section  siunmarizes  the  anal^is  jvocess  and  its  goals. 

This  section  describes  a  series  of  steps  for  analyzing  completeness  and  consistency  of  a  CoRE 
specification.  Wherever  there  are  guidelines  not  supported  ly  strict  rules,  you  are  given  heuristics. 

12.1  MONITORED  AND  CONTROLLED  VARIABLES 

All  monitored  and  controlled  variables  that  are  measured  or  affected  by  the  system  have  been  defined 
in  a  boundary  class. 

Completeness  •  There  is  a  definition  for  each  monitored  or  controlled  variable  in  the 

specification.  Each  variable  is  defined  in  a  boundary  class. 

•  All  the  relevant  attributes  for  all  monitored  and  controlled  variables 
have  been  specified. 

Consiaeacy  •  Thereisonlyonedefinitionfor  each  monitored  or  controlled  variable 

in  the  specification. 

•  The  attributes  of  each  variable  (i.e.,  type,  range,  and  precision)  are 
consistent  with  any  NAT  constraints  for  the  variable. 

•  The  context  diagram  shows  one  incoming  arrow  from  an  entity  to  the 
software  for  eadi  monitored  variable  and  one  outgoing  arrow  from  the 
software  to  an  entity  for  each  controlled  variable. 

•  The  dependency  graph  shows  one  incoming  arrow  for  eadi  monitored 
variable  terminating  at  the  boundary  class  that  defines  the  variable 
and  one  outgoing  arrow  for  each  monitored  variable  originating  at  the 
boundary  class  that  defines  the  variable. 

12.2  CONTROLLED  VARIABLE  FUNCTIONS 

The  REQ  relation  has  been  fully  and  consistently  defined  for  every  controlled  variable. 

Completeness  •  There  is  a  REQ  relation  defined  for  each  controlled  variable  in  the 

boundary  class  that  defines  the  controlled  variable.  All  parts  of  the 
relation  are  defined,  in  particular: 
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Consistettcy 


-  There  is  a  value  function  defined. 

-  Where  applicable,  there  is  an  accuracy  tolerance  function 
defined. 

-  There  is  a  timing  tolerance  function. 

The  definition  of  eadi  function  is  mathematically  complete  according 
to  the  detailed  process. 

The  function  is  defined  for  every  mode  of  the  applicable  mode 
machine.  It  depends  on  every  state  permitted  by  the  NAT  relation. 

The  parts  of  the  REQ  relation  definition  are  mutually  consistent,  and 
the  relation  is  consistent  with  the  controlled  variable  definition  (i.e., 
with  the  type,  range,  and  precision  of  the  variable). 

The  value  function  maps  each  value  of  the  monitored  variables  in  its 
domain  to,  at  most,  one  value  in  the  range. 

Every  mode  used  is  defined  by  exactly  one  mode  machine. 

Every  term  used  is  defined  in  the  encapsulating  class  or  on  the 
interface  of  some  other  class. 

There  is  an  arrow  in  the  dependency  graph  for  each  term  defined  by 
one  class  and  used  by  another  class.  The  arrow  originates  fi'om  the 
defining  class  and  terminates  at  the  using  class. 


12  J  TERMS  AND  MODES 


Every  term  is  fully  defined  and  properly  used.  Every  mode  class  is  completely  defined. 


Compktenas 


Consistency 


•  Every  term  has  a  definition. 

•  Every  mode  is  defined  by  exactly  one  mode  madiine.  The  definition 
of  each  mode  machine  is  complete  as  specified  in  the  detailed  process 
for  evaluating  mode  machines. 

•  Any  term  defined  in  one  cl^  and  used  in  another  is  provided  on  the 
interface  section  of  the  defining  class. 

•  Any  term  defined  in  the  encapsulated  part  of  a  class  is  not  used  outside 
the  class. 

•  Every  term  is  defined  exclusively  as  an  expression  on  monitored 
variables,  constants,  and  other  terms. 

•  The  dependent^  graph  shows  an  arrow  for  every  term  or  mode  class 
used  by  the  defining  class  but  defined  by  another  class.  The  arrow 
originates  in  the  defining  class  and  terminates  in  the  using  class. 
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•  The  definition  of  every  mode  madiine  satisfies  the  criteria  for 
consisteniy  in  the  detailed  process  for  evaluating  mode  dasses. 

12.4  IN  AND  OUT  RELATIONS 

There  is  an  IN  relation  defined  for  every  monitored  variable  and  an  OUT  relation  defined  for  every 

controlled  variable.  The  IN,  OUT,  and  the  input  and  output  variable  spedfications  are  complete  and 

internally  consistent. 

Com^etmess  *  There  is  at  least  one  IN  relation  defined  for  eadi  input  variable  in  the 

specification.  The  definition  of  each  IN  relation  is  comjdete  and 
internally  consistent. 

•  There  is  at  least  one  OUT  relation  defined  for  each  output  variable  in 
the  spedfication.  The  definition  of  eadi  OUT  relation  is  complete  and 
internally  consistent. 

•  There  is  a  definition  for  each  input  or  output  variable  in  the 
specification.  The  variable  specification  is  complete  according  to  the 
detailed  process  description  (i.e.,  all  applicable  parts  of  the  template 
are  filled  in). 

Conastency  •  There  is  at  least  one  IN  relation  for  each  input  variable  and  at  least  one 

OUT  relation  for  eadi  output  variable. 

•  Each  IN  and  OUT  relation  is  complete  and  consistent  according  to  the 
detailed  process  desoiption. 

•  The  IN  relation  and  input  variable  are  defined  in  the  dass  that  defines 
the  corresponding  monitored  variable. 

12.5  GLOBAL  CHECKS 

Make  additional  checks  for  consistency  or  completeness  between  CoRE  relations. 

Completeness  *  Check  that  every  monitored  variable  and  every  term  is  used  in  at  least 

one  REQ  relation. 

Consistency  •  For  a  given  controlled  variable,  the  delays  allowed  by  the  IN  and  OUT 

relations  must  be  consistent  with  the  timing  tolerance  for  the  REQ 
relation;  i.e.,  the  maximum  delay  required  to  read  the  inputs  plus  the 
maximum  delay  required  to  set  the  outputs  must  be  less  Aan  the 
maximum  delay  allowed  by  the  controlled  variable  tolerance. 
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APPENDIX  A.  SOFTWARE  REQUIREMENTS  FOR 
THE  FUEL  LEVEL  MONITORING  SYSTEM 


A.1  INTRODUCTION 

The  design  of  the  FLMS  comprises  automatic  or  manual  control  mechanisms  (engine  and  fuel-level 
controls)  and  safety  monitoring  devices.  The  safety  monitoring  devices  include  fuel  gauges  and  gauge 
codts  that  convey  Ae  fuel  level  in  the  tank,  fusible  plugs  or  fuse  alarms  that  alert  the  operator  when 
the  fuel  level  is  too  low,  and  fuel  flow  rate  gauges  or  other  gauges  showing  the  engine  operating 
condition.  The  FLMS  is  intended  to  replace  or  complement  the  above-mentioned  devices.  It  monitors 
and  displays  the  fuel  level  in  the  tank  and  provides  visible  and  audible  alarms  for  high  and  low  fuel 
levels.  the  currently  selected  hardware  configuration,  fuel  level  is  displayed  in  a  window  on  a 
CRT  display,  two  “armunication”  windows  on  the  CRT  provide  visible  indication  of  exceeded  fuel-lev¬ 
el  limits,  and  the  computer’s  speaker  provides  an  audible  alarm. 

A.2  REQUIREMENTS  FOR  THE  FUEL  LEVEL  MONITORING  SYSTEM 

(1)  The  FLMS  shall  monitor  the  fuel  level  in  the  tank. 

(2)  When  the  level  in  the  tank  exceeds  the  upper  or  lower  limits,  an  alarm  is  triggered.  (3)  If  the  fuel 
level  is  out  of  limits  for  more  than  the  shutdown  lock  time,  the  pump  shall  be  shut  down.  (4)  It  shaU 
be  possible  to  restart  the  system  when  the  fuel  levels  are  again  within  limits. 

(5)  If  the  system  is  unable  to  determine  the  fuel  level  of  the  tank,  the  system  shall  notify  the  operator 
of  the  condition  and  shut  down  the  pump. 

(6)  A  capability  to  conduct  system  self-testing  shall  be  provided.  (7)  System  self-test  shall  be  possible 
at  aity  time.  (8)  On  initiation  of  a  self-  test,  the  system  shall  shut  down  the  pumps.  (9)  A  self-test  shall 
not  keep  the  system  offline  for  longer  than  15  seconds.  (10)  At  the  conclusion  of  a  self-test,  it  shall  be 
necessary  to  restart  the  system. 

(11)  The  operator  shall  be  provided  with  reset  and  test  switches.  (12)  The  system  shall  display  fuel 
level  and  status  alarms  to  the  operator.  (13)  Indications  of  low  or  high  fuel  levels  (hazardous 
conditions)  or  unknown  fuel  levels  shall  be  presented  to  the  operator.  (14)  Whenever  there  is  a 
hazardous  condition  or  an  unknown,  the  system  shall  provide  audible  and  visual  alarms. 
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B.1  SYSTEM  CONTEXT 

Figure  B-1  illustrates  the  context  of  the  FLMS.  Hie  bubble  ref^^esents  the  FLMS  ^tem.  Inputs  to 
the  FLMS  are  the  monitored  variables.  Outputs  are  the  controlled  variables. 


RgureB*!.  Riel  Level  McHiitoring  System:  Context  Diagnun 


B-S 


AppcadiiB.  Core  Sptdtotkw  of  the  Soft»iw»RequireiiiMtt  tor  the  Riel  LwclMoMloriHSlWiMi 


B.2  FUEL  LEVEL  MONITORING  SYSTEM  DEPENDENCY  GRAPH 

Figure  B-2  illustrates  the  dependency  graph  of  this  specification.  It  is  die  detailed  view  of  the  FLMS 
bubble  in  Hgure  B-1.  Arcs  entering  the  diagram  firom  outside  represent  monitored  variables,  and  arcs 
leaving  the  diagram  represent  controlled  variables.  There  is  an  internal  arc  where  a  class  uses 
requirements  information  defined  by  the  interface  of  another  class. 


Figure  B-2.  Fuel  Level  MtxiiU^g  System  Dependent^  Grajd! 
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B3  MODE_CLASS_IN_OPERATION 

niodejclass_In_Operation  defines  the  FLMS  modes.  It  encapsulates  the  rules  for  determining  the 
current  mode  and  the  events  that  trigger  transitions  among  the  modes. 

B3.1  Class  Interface 


Modes  Other  Classes  Are  Allowed  to  Use 


Mode 

iiiode_Operatiiig 

inode_Hazard 

modejShutdown 

modejihst 

inode_BadLevDev 


Constants,  Events,  and  Ihnns  Other  Classes  Are  Allowed  to  Use 


Name 

termJRstjnme 


B3  Encapsulated  Information 

Constant,  Event,  and  Ihrm  CKossaiy 


Name 

Type 

\Uoes 

D^hdtkm 

ooiist_Shutdown_Lodt_'nnie 

TIME 

2.0$ 

oonstJMaxJIhstjnme 

TIME 

14.0  s 

teimjlfestjllme 

TIME 

DURAnON(INMODE(modeJIfest)) 
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Mode  Tiansitioiu:  modejdass_Itt_Opentioa 


Current  Mode 

1 

1 

j' 

o  e 

1  A 

1 

1 

il 

1, 

u 

u 

S  M 
ft  ^ 

event_Selftest 

^1 

New  Mode 

mode_Operatuig 

@F 

mode_Hazaid 

@T 

modejibst 

@T 

inode_BadLevDev 

mode_Hazaid 

@T 

f 

mode_Openting 

@T 

modejShutdown 

@T 

mode_T»t 

@T 

inode_BadLevE>ev 

mode_Shatdown 

t 

@T 

mode_Operatmg 

@T 

modejlbst 

@T 

mode_BadLevDev 

modeJTest 

@t” 

inode_Shutdowii 

@T 

inode_BadLevDev 

mode_BadLev£)ev 

BJ3  Traceabiuty 

The  following  capabilities  from  Softv”-  '  Requirements  for  the  FLMS  (see  Appendix  A)  are  fully  or 
partially  satisfied  by  this  dass; 

(3)  If  the  fuel  level  is  out  of  limits  for  more  than  the  shutdown  lock  time,  the  pump  shall  be  shut 

down. 


(9)  A  self-test  shall  not  keep  the  system  offline  for  longer  than  15  seconds. 

(10)  At  the  conclusion  of  a  self-test,  it  shall  be  necessaiy  to  restart  the  system. 
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B.4  CLASS_FUEL_TANK 

class_Fuel_'nink  provides  the  information  needed  to  determine  the  current  fuel  level;  whether  the  fuel 
level  is  above,  below,  or  within  safe  limits;  and  whether  the  fuel  level  is  within  the  hysteresis  bounds. 
It  encapsulates  the  constants  and  rules  for  determining  whether  the  fuel  level  is  within  safe  or  hysteresis 
limits.  It  also  encapsulates  how  the  software  can  determine  the  values  of  nK}n_Fuel_Levd  and 
monJFuel_Level_Unknown. 

B.4.1  Class  Interface 

Eavironmental  VariaUe  Glossary 

Name  lype  \^hies  Physical  Interpretation 

mon_I\iel_Level  LENGTH  0.0.  J0.0  Level  of  fuel  in  the  tank,  in  centimeters  (cm), 

along  the  vertical  axis  on  the  left  side  of  the  tank, 
S  cm  from  the  front  edge.  The  level  is  measured 
with  respect  to  the  scale  (see  Figure  B-3). 

mon_Riel_Level_Uoknown  BOOLEAN  false  The  system  is  able  to  obtain  the  information 

required  to  determine  the  value  of  fuel  level  to 
the  required  accuracy. 

true  The  ^tem  is  unable  to  obtain  the  information 
required  to  determine  the  value  of  fuel  level  to 
the  required  accuracy. 


Figure  6-3.  Fuel  Level  Monitoring  System  Pump  and  l^nk  Configuration  (Rent  \fiew) 


Constants,  Events,  and  Ifenns  Other  Classes  Are  Allowed  to  Use 


Name 

term_Ftiel_LeveI_Range 

term_lBside_Hys_Range 

BA.1.1  NAT  Relation 


|dmon_FueI_Level|  _  ,  ^ 

F— ^ —  S  const_Max_Level_Rate 

-0.4  an  ^  mon_Fuel_LevcI  s  30.0  an 


B.4^  Encapsuiaud  Information 


Constant, 

Event,  and  Iferm 

Glossary 

Name 

Type 

\hfaie 

Definition 

const_High_Riel_Limit 

LENGTH 

26.0  cm 

oonst_Hysteresis 

LENGTH 

OJtcm 

const_LCB 

LENGTH 

13.0  cm 

oonst_Low_Riel_Limit 

LENGTH 

14.0  cm 

oon8t_Max_Level_Rate 

LENGTHTTIME 

0.37S  cmjs 

const_UCB 

LENGTH 

27.0  cm 

term_Fhel_Level_Range 

ENUMERATED 

levellow 

mon_Fiicl_Level  const_Low_Riel_Limit 

withinlimits 

const JLowJHidJJmit  <  m(m_RidJLevel 
<  oonst_Hi^_I^l_Limit 

levelhigh 

mon_FlielJLevel  ^  oonstJEfi^_Fhel_Liniit 

teim_Inside_Hys_Range 

BOOLEAN 

true 

(constJLow_RielJLimit  + 

const_Ifysteresi5)  <  mon_Riel_Level  < 
(const_IEgh_Fhel_Limit  — 
const^Hysteresis) 


false  (oonst_Low_Ftiel_Linut  + 

const_ItyBteresis)  ^  monJPliel_Level  OR 
mon_Fliel JLevel  ^ 
(oonst_High_FhelJLimit  — 
const_Hysteresis) 

B.4,2.1  Input  Variables 

Differential  Pressure  Unit 


Acronym 

Hardware 

\hlaes 

Data  Ihins&r 
Data  Representation 


inJDiff_Press 
Differential  Pressure  Unit 
[0..2551 
ADC(0) 

S-trit  unsigned  integer 
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B.4.2.2  IN  Relation 

in_Diff_Press  reflects  the  value  of  mon_Fuel_Level.  The  device  is  calibrated  so  that  it  has  a  value  in 
the  range  [1 ..254]  when  tnon_Fuel_Level  is  between  13.0  cm  (const_LCB)  and  27.0  cm  (const_UCB). 
A  value  of  0  for  in_Diff_Press  indicates  that  mon_Fuel_Level  has  fallen  below  the  lower  calibration 
bound  (const  JLCB)  or  that  the  device  has  failed.  A  value  of  255  indicates  that  mon_Fuel_Level  has 
risen  above  the  upper  calibration  bound  (const_UCB)  or  that  the  device  has  failed.  When  we  cannot 
distinguish  failure  of  in_Diff_Press  from  mon_Fuel_Level  going  outside  of  the  calibration  bounds,  we 
assume  that  the  device  has  failed. 


Determining  the  Value  of  in_Diff_Press 

Wriable 

in_DiffPress 

Error 

0.1  cm 

Delay 

0.2  s 

Condition 

mon_Ftiel_Level  < 

const  LCB<mon  Fhel  Level  <  const  UCB 

mon  Fhel  Level  > 

const_LCB 

const_UCB 

in_Di£f_Press  =  0 

in_Diff_Pressin  [1  ..254] 

in_Diff_Press  =  255 

in__Diff_Press  reflects  the  value  of  mon_Fuel_Level_Unknown.  When  in_Diff_Press  has  a  value  of 
either  0  or  255,  we  assume  that  in_Diff_Press  has  failed  and  that  the  FLMS  is  unable  to  determine 
the  value  of  mon_Fuel_Level. 

Determining  the  Value  of  in_Diff_Press 

Variable  in_Diff_Press 

Error  N/A 

Delay  0.2  s 


Condition 


mon_Fuel_Level_Unknown 

NOT  mon_Fuel_Level_Unknown 

in_Diff_Press  =  0  OR  in_Diff_Press  =  255 

in_Diff_Press  in  [1 ..  254] 

The  following  expression  describes  how  the  value  of  mon_Fuel_Level  can  be  calculated  from  the  value 
of  in_Diff_Press: 

mon_Fuel_Level  =  ^  (const_UCB  -  const_LCB)  const_LCB  ±  0.28  cm 

The  input  variable  in_Diff_Press  has  a  precision  of 

const_UCB-const_LCB  27.0-13.0  _ 

- ^4 - B4~  " 

which  is  sufficient  to  represent  mon_Fuel_Level  to  the  required  0.5  cm.  The  maximum  error 
introduced  by  the  delay  of  0.2  s  is 
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0.2  s  X  const_Max_Fuel_Rate  =  0.2  s  x  0.375  cm/*  *  0.075  cm 

The  maximum  error  introduced  by  the  device  error  and  delay  of  in_Diff_Press  is  the  sum  of  the  two, 
0.175  cm,  which  satisfies  the  needs  of  the  FLMS  to  determine  the  value  of  mon_Fuel_Level  to  0.5  cm. 

B.43  TRACEABtUTY 

The  following  capability  from  Software  Requirements  for  the  FLMS  (see  Appendix  A)  is  fully  or 
partially  satisfied  by  this  class: 

(1)  The  FLMS  shall  monitor  the  fuel  level  in  the  tank. 


B-12 


Appendg  B.  CoRE  Specification  of  the  Software  Requirements  for  the  Fuel  Level  Monitoring  System 


B.5  ClASS^PUMP 

class_Pump  encapsulates  the  rules  that  determine  the  required  behavior  of  the  pump  and  the 
mechanisms  available  to  the  software  to  support  the  required  behavior. 

Class  Interface 

None. 


B.5.2  Encapsulated  Information 

Environmental  Variable  Glossary 


Name 

Type 

Valnea 

Physical  Interpretation 

con_Shntdown_Relay 

ENUMERATED 

dosed 

The  fuel  pump  shutdown  relay  is  dosed,  and  the 
fuel  pump  is  enabled. 

open 

The  fuel  pump  shutdown  relay  is  open,  and  the  fuel 
pump  is  disabled. 

B.5JL1  REQ  Relation 

The  FLMS  disables  the  pump  under  unsafe  unconditions  and  tests  the  mechanism  for  disabling  the 
pump. 

Behavior  of  conjShutdown_Relay 

Variable  con_Shutdown_^Relay 

Initial  Value  See  value  function 

Mode  Class  mode_dass_In_C)peration 

Sustaining  Condition  true 


Mode 

Events 

mode_Operating 

X 

ENTERED 

mode_Hazard 

X 

X 

modejShutdown 

mode_BadLevDev 

modejibst 

ENTERED 

X 

con_Shutdown_Relay 

open 

dosed 

Tolerance 

N/A 

Initiation  Delay 

Oms 

Completion  Deadline 

SO  ms 
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Output  \^riables 

Shutdown  Signal 


Acronym 

out_Shutdown 

Hardware 

Pump  Shutdown  Relay 

'\blucs 

false  (lb) 

true  (Ob) 

Data  Ihinsfer 

PortC 

Data  Representation 

Bit  1  of  byte 

OUTRdation 

Setting  the  Value  of  con_Shutdown_Relay 

^^uiaMe 

oon_Shutdown_Relay 

Error 

N/A 

Delay 

10  ms 

Condition 


out Shutdown  =  true 

out_Shutdown  =  false 

conjShutdown_Relay  =  open 

con_Shutdown_Relay  =  dosed 

B  Traceabilfty 

The  following  capabilities  from  Software  Requirements  for  the  FLMS  (see  Appendix  A)  are  fully  or 
partially  satisfied  by  this  class: 

(3)  If  the  fuel  level  is  out  of  limits  for  more  than  the  shutdown  lock  time,  the  pump  shall  be  shut 
down. 

(4)  It  shall  be  possible  to  restart  the  system  when  the  fuel  levels  are  again  within  limits. 

(5)  If  the  system  is  imable  to  determine  the  fuel  level  of  the  tank,  the  system  shall  notify  the 
operator  of  the  condition  and  shut  down  the  pump. 

(6)  A  capability  to  conduct  system  self-testing  shall  be  provided. 

(7)  System  self-test  shall  be  possible  at  any  time. 

(8)  On  initiation  of  a  self-test,  the  system  shall  shut  down  the  ptunps. 
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B.6  CLASS_TIME 

classJUme  encapsulates  the  mechanisms  available  to  the  software  to  determine  the  values  of  the  mon¬ 
itored  variables  associated  with  the  passage  of  time. 

B.6.1  Class  Interface 

Environmentai  Variable  Glossary 

Name  lype  Values  Physical  Interpretation 

monjnme  TIME  0 ..  31.536  x  10^  Hme,  in  mOliseconds  (ms),  since  system 

initialization 

B.6^  Encapsuiated  Information 
B.6J.1  Input  Variables 

System  Timer 


Acronym 

Hardware 

Valnea 

Data  Ihinsfer 
Data  Representation 


injGkPulse 
System  timer 
None 

Interrupt  (ICh) 
None 


IN  Relation 


\hriable 

Error 

Delay 


Determining  the  Value  of  in_Clk_Pulse 

in_Qk_Pulse 

N/A 

Ims 


Events 


@T(mon_'nme  mod  55  =  0) 

@F(mon_Time  mod  55  =  0) 

in_Qk_Pulse  defined 

in_Clk_Pulse  undefined 

B.63  TRACEABimY 

The  following  capabilities  from  Software  Requirements  for  the  FLMS  (see  Appendix  A)  are  fully  or 
partially  satisfied  by  this  class: 

(3)  If  the  fuel  level  is  out  of  limits  for  more  than  the  shutdown  lock  time,  the  pump  shall  be  shut 

down. 


(9)  A  self-test  shall  not  keep  the  system  off  line  for  longer  than  15  seconds. 
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B.7  CIASS_OPERATOR 

dlass_Operator  encapsulates  how  the  FLMS  is  required  to  interact  with  the  operator  and  the 
mechanisms  available  to  the  software  to  support  the  required  interactions. 

B.7.1  Class  Intekface 

Constants,  Events,  and  Ibrms  Other  Classes  Are  Allowed  to  Use 


Name 

event_SeIftest 

event_Reset 

B.7.2  Encapsulated  Information 


tenn  lest  Thne 


mode_class_In_Operation  _ 
term  Fuel  Level  Rangc  ^  |  cUss_OiMrator_ 

mon  Fuel  Levd 


mon  lime 


coD_Audible_Alami 

oon_High.Alann 

CQn_Lcw_Alanii 

con_Level_Di^lay 


D^iendency  Graph  for  Operator  Interface 


B.73  Traceabiltty 

See  encapsulated  classes. 
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B.8  CLASS_OPERATOR_COMMUNICATION 

class_Operator_Coinmunication  encapsulates  the  rules  that  determine  how  the  FLMS  communicates 
to  the  operator  and  the  mechanisms  available  to  the  software  to  support  this  conununication. 

B.8.1  Class  Interface 
None. 


B.8.2  Encapsulated  Information 

Environmental  VariaUe  Glossary 


Name 

Type 

>^lues 

Physical  Interpretation 

con_High_Alarm 

ENUMERATED 

on 

The  alarm  labeled  “FUEL  LEVEL  HIGH” 
is  visible  to  the  operator. 

off 

The  alarm  labeled  “FUEL  LEVEL  HIGH” 
is  not  visible  to  the  operator. 

con_Level_Display 

REAL 

0.0..99.9 

The  value  conveyed  by  the  display  labeled 
“FUEL  LEVEL.” 

oon_Low_Alarm 

ENUMERATED 

on 

The  alarm  labeled  “FUEL  LEVEL  LOW” 
is  visible  to  the  operator. 

off 

The  alarm  labeled  “FUEL  LEVEL  LOW” 
is  not  visible  to  the  operator. 

con_Audible_Alarm 

ENUMERATED 

sound 

The  audible  alarm  is  sounding. 

sflent 

The  audiUe  alarm  is  sflent 

Constant,  Event,  and  Term  Qossary 


Name 

■Qpe 

Values 

DeGnition 

const_High_Alarm_Col 

INTEGER 

9 

const_High_Alarm_Row 

INTEGER 

17 

constJLevel_Display_Row 

INTEGER 

6 

constJLow_Alarm_Col 

INTEGER 

29 

const_Low_Alarm_Row 

INTEGER 

17 

const_MaxCol 

INTEGER 

39 

const JMaxRow 

INTEGER 

24 

constJMinCol 

INTEGER 

0 

const_MiiiRow 

INTEGER 

0 

term_Digit(x,  k) 

CHARACTER 

4 

r  X  mod  10*+*  if-^  0 
'  in* 

1  if-i-  =  0 

space  “  10*  ^ 

term_Flash_On 

BOOLEAN 

true 

monJTime  mod  1000  <  500 

false 

mon  Time  mod  1000  ^  500 
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Name 


'Qrpe  Velnes  Dcfiaitioii 


tenn_Lcvcl_Display_Digit(i)  INTEGER 


event_SetDigit(x,  i)  EVENT 


'20  ifi  =  0 
18  if  i  =  1 
‘  17  ifi  =  2 
16  ifi  =  3 

I. 

@T(out_Charactcr  =  tcrm_Digit(x, 
i))  WH^  out_Cursor_Row  = 
Coiist_Lcvel_^lday_Row  AND 
out_Cursor_Col  =  term_Level 
_Dis|day_ESgit(i) 


REQ  Relation 

The  FLMS  informs  the  operator  when  mon_Fuel_Level  is  too  high,  informs  the  operator  ^en  the 
ELMS  is  unable  to  determine  whether  monJFuel_Level  is  too  high,  and  tests  the  mechanism  for 
informing  the  operator. 

Behavior  of  con_High_Alann 


ControOed  Variable  Name 
Initial  Vhlue 
Mode  Class 
Sustainii^  Conditions 


con_High_Alaim 

(coa_High_A]arm  =  on),  ^stem  init 

mode_dass_InjOpeiation 

true 


Mode 

Events 

mode_Operating 

X 

ENTERED 

mode_Hazard 

ENTERED  WHEN  term_Riel_LeveI_Range 
=  levelhigh  OR  @T(term_Fuel_Level_Range 
=  levelhigh) 

@F(teim_RieI_Level_Range  = 
levelhigh) 

mode_Shutdown 

X 

X 

modejihst 

ENTERED 

@T(term_'Ifest_’Ilme  ^  2) 

mode_BadLev£>ev 

@T(term_Flash_On) 

@F(term_Flash_On) 

con_High_Alarm 

on 

off 

Iblerance  N/A 

Initiation  Delay  0  ms 

Completion  Deadline  100  ms 
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The  ELMS  informs  the  operator  of  the  value  of  mon_Fuel_Level  and  tests  the  mechanism  for 
informing  the  operator. 


Behavior  of  oon_Level_Display 


Contrdled  \Mabie  Name 
Initial  \%liie 
ModeC3au 
Sustaining  Conditions 


Gon_Level_Dtsplay 
See  value  function 
modejd[ass_In_C)peiation 
true 


Mode 

Event 

m0de_Operating 

mode_Hazard 

mode_Shutdown 

ENTERED  OR 
@T( 

|m(m_FhelJLevel  — 
con_Level_Dis|day  | 
^d!5cm 

X 

X 

X 

modejihst 

X 

ENTERED  OR 
@T( 

term  Ibst  Time  ^ 

14)  ‘ 

@T(tetm  Tfest  Time  ^ 

4) 

X 

mode_BadLevDev 

X 

X 

X 

ENTERED 

oon_Level_Display 

mon_FUel_Level 

0.0 

L(tetm  Tfest  Time  -  4)J 

X  11.1 " 

99.9 

Tbierance  0.5  cm 

Initiation  Delay  0  ms 

Completion  Deadline  500  ms 


The  FLMS  informs  the  operator  when  monJPhel_Level  is  too  low,  informs  the  operator  ^en  the 
FLMS  is  unable  to  determine  whether  mon_FhelJLevel  is  too  low,  and  tests  the  medianism  for  in¬ 
forming  the  operator. 

Controlled  Variable  Name 
Initial  Value 
Mode  Class 
Sustaining  Condition 


Behavior  of  conJLow_Alaim 
con_Low_Alarm 

(oon_Low_Alarm  «=  on),  ^tem  init 

mode_dass_In_Operation 

Ihie 
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Mode 

Events 

iDode_Operating 

X 

ENTERED 

mode_Hazard 

ENTERED  WHEN  term_RieI_Level_Range 
=  levellow  OR  @T(term_Fuel_Level_Range 
=  levellow) 

@F(term_Fiiel_Level_Raoge  *= 
levellow) 

mode_Shutdown 

X 

X 

modejlhst 

@T(tenn_'ftst_Time  >  2) 

@T(teiin_'Ibst_T1me  ^  4) 

mode_BadLevDev 

@T(term_Flash_On) 

@F(term_Flash_On) 

con_Low_Alann 

on 

off 

Tbkraiice  N/A 

Initiatioii  Delay  0  ms 

Completion  Deadline  100  ms 

The  FLMS  attracts  the  operators  attention  when  mon_Fuel_Level  has  an  unsafe  value  and  when  it 
is  unable  to  determine  the  value  of  mon_Fuel_Level,  and  it  tests  the  mechanism  for  attracting  the 
operator’s  attention. 

Behavior  of  con_AudiUe_Alarm 
Controlled  Variable  Name  con_Audible_Alann 

Initial  ^^hie  (coa_Audible_Alann  =  silent).  System  initialization 


Mode  Class 

mode_dass_In_Operation 

Sustaining  Condition 

True 

Mode 

Events 

mode_Operating 

X 

ENTERED 

mode_Hazard 

ENTERED  OR 

@F(teTm  Fuel  Level  Range  =  withinlimits) 

@T(term_FheI_LeveI_Rangp  = 
withinlimits) 

mode_Shutdown 

X 

X 

modeJTest 

@T(term_Test_'nme  >  0) 

@T(term_'Ifest_T1me  >  4) 

mode_BadLevDev 

ENTERED 

X 

con_Audible_Alann 

sound 

silent 

Iblerance 

N/A 

Initiation  Delay 

0ms 

Completion  Deadline 

100  ms 
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B.8JLZ  Output  Variables 


Cursor  IVuition 


Acroujm 

Hardware 

Vdnes 

DataThuisfer 


Data  Representation 


Acronym 

Hardware 

\^dncs 


outjCursor_Row 

out_Cuisor_Col 

Console 

oonst_Min_Row  ^  out_Cunor_Row  ^  const_Max_Row 

0(Mist_MinjC(d  s  ont_CuisorjCol  &  oonst_MaxjC(d 
Softint  (lOh),  function  Q2h 

ontjCuisor_How  8088  register  DH 

ont_Ctiisor_Col  8088  register  DL 
8-bit  unsigned  integer 

Screen 


ontjCharacter 
Console 
space  32 

period  46 


block  219 

Data  Ihuisfer  Softint  (lOh),  function  OEh,  8088  register  AL 

Data  Representation  8-bit  unsigned  integer 

OUT  Relation 

Setting  the  Value  of  con_High_Alarm 


Events 

@T(out_Character  =  space) 
WHEN  out_Cursor_Row  = 
const_Higli_Alarm_Row  AND 
out_Cursor_Col  = 
const_High_Alann_Col 

@T(out_Character  =  blodc) 
WIffiN  out_Cursor_Row  = 
const_HigJi_Alann_Row  AND 
out_Cursor_Col  = 
const_High_Alann_Col 

@T(out_Cbaracter  ^  blodc 

AND  out_Character  space) 
WHEN  out_Cursor_Row  = 
const_High_Alann_Ro>v  AND 
out_Cuisor_Col  = 
const_High_Alarni_Col 

oon_High_Alarm  off 

con_High_Alami  =  on 

oon_High_A]arm  undefined 
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Setting  the  Vblue  of  ooa_Low_A}arm 


Events 

@T(out_Character  =  space) 
WHEN  out_Cursor_Row  = 
const_Low_Alann_Row  AND 
out_Cuisor_Col  = 
const_Low_Alann_Col 

@T(out_Character  =  block) 
WHEN  out_Cursor_Row  = 
const_Low_Alarm_Row  AND 
out_Cursor_Col  * 
const_Low_Alann_Col 

@T(out_Cbancler  ^  Nock 

AND  out_Cbaracter  ^  space) 
WHEN  out_Cursor_Row  = 
const_Low_Alarm_Row  AND 
out_Cuisor_Col  = 
coiist_Low_Alann_Col 

LxiwAIann  —  off 

LowAlarm  =  on 

LowAlarm  unife^net/ 

Setting  the  Value  of  con_Leve]_Display 
Events 

event_Set_Digit(X,  0)  AND  event_Set_Digit(X,  1)  AND  event_Set_Digit(X,  2)  AND 
event_Set_Digit(X3) 

con_Level_Display  =  X 


Setting  the  Value  of  con_Audible_Alarm 


Events 


@T(out_Character  =  bel) 

@T(DURAnON(out_Character  *  bel)  >  0.5  s) 

con_AudiWe_Alarm  =  sound 

con_Audible_Alarm  =  silent 

B.8  J  Traceabiuty 

The  following  capabilities  from  Software  Requirements  for  the  FLMS  (see  Appendix  A)  are  fully  or 

partially  satisfied  by  this  class: 

(2)  When  the  level  in  the  tank  exceeds  the  the  upper  or  lower  limits,  an  alarm  is  triggered. 

(5)  If  the  system  is  unable  to  determine  the  fuel  level  of  the  tank,  the  system  shall  notify  the 
operator  of  the  condition  and  shut  down  the  pump. 

(6)  A  capabilify  to  conduct  system  self-testing  shall  be  provided. 

(12)  The  system  shall  display  fuel  level  and  status  alarms  to  the  operator. 

(13)  Indications  of  low  or  high  fuel  levels  (hazardous  conditions)  or  unknown  fuel  levels  shall  be 
presented  to  the  operator. 

(14)  Whenever  there  is  a  hazardous  condition  or  an  unknown,  the  system  shall  provide  audible  and 
visual  alarms. 
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BJ9  CIASS_SWITCH 

dass_Switch  encapsulates  the  mechanisms  available  to  the  software  to  determine  the  values  of 
switches  that  can  1m  set  the  user  and  the  rules  that  determine  when  the  FLMS  considers  the  user 
to  have  requested  a  selftest  or  reset  of  the  FLMS. 

B.9.1  Class  Interface 

Definitions  Other  Qasses  Are  Allowed  to  Use 

Name 

event_Reset 

event_Selftest 

BS.2  Encapsuiaied  Information 

Environmental  Variable  CMossaiy 

Name  '^pe  Vdues  Physical  Interpretation 

mon_Reset_Switch  ENUMERATED  pressed  The  push  button  labeled  RESET  is  pressed. 

released  The  push  button  labeled  RESET  is  not 

press^ 

monjSelftest^Switch  ENUMERATED  pressed  The  push  button  labeled  SLFTST  is  pressed. 

released  The  push  button  labeled  SLFTST  is  not 

pressed. 

Constant,  Event,  and  Ibrm  Glossary 
Name  'Qipe  Definition 

event_Reset  EVENT  @T(DURAnON(mon_Reset_Switch  =  pressed)  ^  3  s) 

event_Selftest  EVENT  @T(DURAnON(mon_Selftest_Switch  =  pressed)  ^  0.5  s) 

Input  Variables 

Reset  Pushbutton 

Acronym  in_Reset_Device 

Hardware  FLMS  Pushbutton  Array 

Values  on  (lb) 


Data  Transfer 
Data  Representation 


off  (Ob) 

Porte 

ResetDevice  Bit  5  of  l^e 
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Selftest  Pushbutton 

m_Selftest_Device 
FLMS  Pushbutton  Anny 
on  (lb) 

off  (Ob) 

PortC 

SelftestDevioe  Bit  7  of  byte 


Detennining  the  Value  of  in_Reset_Devioe 

in_Reset_Device 

N/A 

10  ms 


Condition 


mon_Reset_Switch  »  pressed 

mon_Reset_Switch  ■>  released 

in^Reset_Device  =  on 

in_Reset_Device  «  off 

Detennining  the  Value  of  in_Selftest_Device 

in_Selftest_Device 

N/A 

10  ms 


Condition 


mon_Selftest_Switch  »=  pressed 

mon_Selftest_Switdi  =  released 

in_Selftest_Device  =  on 

in_Selftest_Device  =  off 

Traceability 

The  following  capability  from  Software  Requirements  for  the  FLMS  (see  ^pendix  A)  is  fully  or 
partially  satisfied  by  this  class: 

(11)  The  operator  shall  be  provided  with  reset  and  test  switches. 

B.10  SAFETY  REQUIREMENTS 

1.  The  pump  shall  not  operate  when  the  system  is  unable  to  determine  the  fuel  level. 

2.  The  pump  shall  not  operate  for  longer  than  the  shutdown  lock  time  with  the  fuel  at  an  unsafe 
level. 


\hriable 

Error 

Delay 


Acronyoi 

Hardware 

^hies 

Datalbansfer 
Data  Representation 

Bdl^  IN  Relation 

^briaUe 

Error 

Delay 
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3.  The  system  shall  always  require  operator  intervention  to  enable  the  pumps  when  they  have 
been  disabled. 

4.  The  pump  shall  not  operate  while  system  self-test  is  being  performed. 

B.11  SECURITY  REQUIREMENTS 
None. 

B.12  OTHER  REQUIREMENTS 
None. 
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APPENDIX  B  INDEX 


Qass 

dass_BielJIknk,  definition  of,  B-9-B-12 
dass_In_(^ration,  definition  of,  B-7-B-8 
dass_Operator,  definition  of,  B-16 
dass  Operator  Conununication,  definition  of, 
B-17-B-22" 

dass_Piimp,  definition  of,  B-13-B-14 
dass_Switch,  definition  of^,  B-23-B-24 
dassjnme,  definition  of,  B-IS 

Constant 

const_High_Alarm_Col 
definition  of,  B-17 
used,B-21 

const_High_Alann_Row 
definition  of,  B-17 
used,  B-21 

const_High_Fuel_Limit 
definition  of,  B-10 
used,  B-10 
const_Hysteresis 
definition  of,  B-10 
used,  B-10 
const^LCB 
definition  of,  B-10 
used,  B-11 

const_Level_Display_Row 
definition  of,  B-17 
used,  B-18 

const_Low_Alarni_Col 
definition  of,  8-17 
used,  B-22 

const_Low_Alarm_Row 
definition  of,  B-l7 
used,  B-22 

const_Low_Fuel_Liniit 
definition  of,  B-10 
used,  B-10 

const_Max_Level_Rate 
definition  of,  B-10 
used,  B-10 

const_Max_Test_Tiine 
definition  of,  B-7 
used,  B-8 
const_MaxCol 
definition  of,  B-17 
used,  B-21 
const_MaxRow 
definition  of,  B-17 
used,  B-21 
const_MinCol 
definition  of,  B-17 


used,  B-21 

const_MinRow,  definition  of,  B-17 
const_Shutdown_Lodc_'nme 
definition  of,  B-7 
used,  B-8 
const_UCB 
definition  of,  B-10 
used,  B-11 

Controlled  variable 
cott_Audible_AlaTm 
definition  of,  B-17 
OUT  relation,  B-22 
REQ  relation,  B-20 
con_High_Alarm 
definition  of,  B-17 
OUT  relation,  B-21 
REQ  relation,  B-18 
con_Level_Display 
definition  of,  B-17 
OUT  relation,  B-22 
REQ  relation,  B-19 
con_Low_Alarm 
definition  of,  B-17 
OUT  relation,  B-22 
REQ  relation,  B-19 
con_Shutdown_Relay 
definition  o^  B-13 
OUT  relation,  B-14 
REQ  relation,  B-13 


Event 

event_Reset 
definition  of,  B-23 
used,  B-8 
event_Selftest 
definition  of,  B-23 
used,  B-8 
event_Set_Digit 
definition  of,  B-18 
used,  B-22 


Input  variable 
in_ClkPnlse 
definition  of,  B-15 
IN  relation,  B-15 
in_Diff_Press 
definition  of,  B-10 
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IN  relation,  B-11 
in_Reset_Device 
definition  of,  B-23 
IN  relation,  B-24 
in_Selftest_Device 
definition  of,  B-24 
IN  relation,  B-24 


mon_'nme 
definition  of,  B-IS 
IN  relation,  B-IS 
NAT  relation,  B-10 
used,  B-17 


Mode 

mode_BadLevDev 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_class_In_C)peration 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_Hazard 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_C)perating 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_Shutdown 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_'Rst 
definition  of,  B-8 
used,  B-7,  B-13,  B-18,  B-19,  B-20 

Monitored  variable 
mon_Fuel_Level 
definition  of,  B-9 
IN  relation,  B-11 
NAT  relation,  B-10 
used,  B-10,  B-19 
mon_Fuel_Level_Unknown 
definition  of,  B-9 
IN  relation,  B-11 
used,  B-8 

mon_Reset_Switch 
definition  of,  B-23 
IN  relation,  B-24 
used,  B-23 
mon_Selftest_Switch 
definition  of,  B-23 
IN  relation,  B-24 
used,  B-23 


Output  variable 
out_Character 
definition  of,  B-21 
OUT  relation,  6-21,  B-22 
used,  B-18 
out_Cursor_Col 
definition  of,  B-21 
OUT  relation,  B-21,  B-22 
used,  B-18 
out_Cursor_Row 
definition  of,  B-21 
OUT  relation,  B-21,  B-22 
used,  B-18 
out_Shutdown 
definition  of,  B-14 
OUT  relation,  B-14 


Term 

tenn_Digit 
definition  of,  B-17 
used,  B-18 
term_Flash_On 
definition  of,  B-17 
used,  B-18,  B-20 
term_FueI_Level_Range 
definition  of,  B-10 
used,  B-8,  B-18,  B-20 
tenn_Inside_Hys_Range 
definition  of,  B-10 
used,  B-8 

term_Level_Display_Digit 
definition  of,  B-18 
used,  B-18 
tenn_Test_’Iime 
definition  of,  B-7 
used,  B-18,  B-19,  B-20 
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APPENDIX  C.  Core  MAPPING  TO  DOD-STD-2167A 


Cl  INTRODUCTION 

DOD-STD-2167A  (DoD  1988)  is  the  Defense  ^tem  Software  Development  standard  that  helps  you 
establish  uniform  requirements  for  software  development  that  are  applicable  throughout  the  ^tem 
life  cyde.  This  section  provides  guidelines  so  that  you  can  format  the  information  found  in  a  CoRE 
spedfication  into  a  Software  Requirements  Spec^cation  (SRS).  This  section  was  written  assuming 
t^t  you  have  access  to  the  standard  and  the  SRS  data  item  descriptions. 

This  section  offers  suggestions  for  using  an  existing  CoRE  software  specification  to  produce  an  SRS. 
The  Consortium  designed  the  CoRE  requirements  specification  to  be  a  “living”  document  (e.g.,  un¬ 
dergoing  constant  change  and  revision);  the  documents  required  by  the  2167A  standard  are  viewed 
as  static  and  produced  to  fulfill  the  needs  of  the  contract,  "l^o  strategies  may  be  employed  to  create 
the  SRS: 

•  Create  the  CoRE  specification  as  a  “living”  document,  and  create  the  SRS  from  a  snapshot 
of  the  CoRE  specification. 

•  Create  the  SRS  and  the  CoRE  specification  in  parallel. 

The  mapping  from  the  elements  of  a  CoRE  specification  to  the  SRS  sections  is  summarized  in  Ikble 
C-1 .  The  first  column  provides  the  table  of  contents  for  the  SRS.  For  each  SRS  section,  the  CoRE  spec¬ 
ification  element  that  should  be  incorporated  into  a  section  is  given  along  with  a  brief  comment.  The 
sections  that  have  no  direct  mapping  from  the  CoRE  specification  are  left  blank.  The  sections  that 
follow  the  table  elaborate  on  the  comments  given  in  Ikble  C-1. 


IkUe  C-1.  Relationship  of  CoRE  Specification  E'ements  to  the  Software  Requirements  Specification 


Software  Requirements  Specification 

CoRE  Specification 

Comment 

1.  Scope 

1.1  Identification 

1.2  CSCI  overview 

13  Document  overview 

2.  Applicable  documents 

2.1  Government  documents 

2.2  Nongovernment  documents 

3.  Engineering  requirements 
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Table  C-1,  continued 


Software  Requirements  Specification 

Core  Specification 

Comment 

3.1  CSCI  externa]  interface  requirements 

Relations  tables  between 
input  and  monitored 
variables  (IN)  and  between 
controUed  and  output 
variables  (OUT) 

Provide  a  brief  description 
for  each  IN  and  OUT 
relation. 

3.2  CSCI  capability  requirements 

Mode  classes  and  their 
dependency  diagrams 

Examine  each  mode  dass  to 
determine  the  various  system 
modes.  Each  dependency 
from  a  mode  class  will  corre¬ 
late  each  capability  to  eadi 
mode. 

3.2.x  (Capability  name  and  project-unique 
identifier) 

Class  structure 

Each  CoRE  class  is 
considered  a  capability.  The 
encapsulation  structure  for 
each  class  dictates  the 
constituent  capabilities 
(Sections  3.2jc.y). 

33  CSCI  internal  interfaces 

Monitored  and  controlled 
variables 

The  system  context  diagram 
may  Iw  presented  in  this 
section. 

3.4  CSCI  data  element  requirements 

Monitored  variables, 
controlled  variables, 
input  variables, 
output  variables 

List  the  definitions  of  the 
monitored  and  controlled 
variables  for  the  internal  data 
items  and  the  input  and  out¬ 
put  variables  for  the  external 
data  items. 

3.5  Adaptation  requirements 

Obtained  from  NAT  relation 

NAT  relation  is  intended  to 
capture  constraints  on  the 
environmental  variaUes. 

Could  also  be  listed  as 
nonfunctional  requirements. 

33.1  Installation-dependent  data 

Obtained  from  NAT  relation 

NAT  relation  is  intended  to 
capture  constraints  on  the 
environmental  variables. 

333  Operational  parameters 

Obtained  from  NAT  relation 

NAT  relation  is  intended  to 
capture  constraints  on  the 
environmental  variaUes. 

3.6  Sizing  and  timing  requirements 

Obtained  from  REQ  relation 

REQ  relation  template 
provides  sizing  and  timing 
information  (tolerance  and 
scheduUng). 

3.7  Safe^  requirements 

Listed  as  nonfunctional 
requirements. 

3.8  Security  requirements 

Listed  as  nonfunctional 
requirements. 

3.9  Design  constraints 

3.10  Software  quality  factors 
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Table  C-1,  continued 


Software  Requirements  Specification 

CoRE  Specification 

Cemment 

3.11  Human  performance/human 
engineering  requirements 

3.12  Requirements  traceability 

4.  Quality  requirements 

4.1  Qualification  methods 

42  Special  qualification  requirements 

5.  Preparation  for  delivery 

6.  Notes 

SOFTWARE  REQUIREMENTS  SPECinCATION 

The  SRS  specifies  the  engineering  and  qualification  requirements  for  a  computer  software 
configuration  item  (CSCI).  The  SRS  is  used  to  provide  the  detailed  requirements  for  a  CSCI  allocated 
from  the  System  Segment  Specification.  It  is  also  used  by  the  contractor  as  the  basis  for  the  design  and 
formal  testing  of  a  CSCI.  Ilie  sections  that  follow  elaborate  on  the  mapping  provided  by  Tkble  C-1. 

C.2.1  SRS  Paragraph  3.1:  CSCI  External  Interface  REQUiREMENrs 

The  Core  IN  and  OUT  relations  and  corresponding  variables  provide  a  desCTiption  of  how  the 
software  reads  or  writes  from  or  to  required  devices  and  software  subsystems.  The  devices  and 
software  subsystems  that  the  CSCIs  are  required  to  use  are  spedfied  in  the  Interface  Requirements 
Specification  or  Interface  Control  Document  for  the  CSCI.  Tlie  variables  and  IN  and  OUT  relations 
provide  traceability  information  needed  by  this  section.  You  need  to  provide  a  brief  description  of 
each  interface. 

C.12  SRS  Paragraph  3.2:  CSCI  Capabhjty  Requirements 

^tem  modes  and  states  provide  a  history  of  one  or  more  of  the  monitored  variables.  Modes  and 
states  are  both  encapsulated  in  CoRE’s  mode  classes.  Tb  identify  the  system  modes  and  states,  ex¬ 
amine  each  mode  class  and  determine  which  modes  are  used  by  other  dasses.  The  dependent  dia¬ 
gram  for  each  mode  class  gives  you  the  capabilities  that  are  affected  by  the  mode.  Each  capability  maps 
to  a  Core  class.  This  information  can  be  captured  in  a  tabular  format  like  the  one  shown  in  Tkble  C-2. 
An  X  in  a  row  correlates  a  capability  or  constituent  capability  to  a  particular  mode. 

Table  C-2.  Example  of  CSCI  System  States  Mapping  to  Capabilities 


modc_das8_in_Operation 

class_Pump 

class_Operator 

mode_Operating 

X 

X 

mode_Hazard 

X 

mode_Shutdown 

X 

modeJTest 

X 

X 

mode_BadLevDev 

X 

X 
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CJL3  SRS  Paragraph  3.2.x:  (Capability  Name  and  Project-Unique  Identifier) 

The  capabilities  of  a  CSCI  correspond  to  the  classes  identified  on  the  top-level  dependency  graph 
(level  0).  Each  of  these  classes,  in  turn,  can  be  decomposed  into  subordinate  classes.  This  imposes  a 
hierarchy,  called  the  encapsulation  structure,  where  the  subordinate  classes  become  constituent 
capabilities.  Hierarchical  requirements  structures  have  normally  been  used  to  simplify  expressing  the 
capabilities  of  a  CSCI;  with  CoRE,  a  hierarchical  structure  is  cx^eated  to  help  manage  the  requirements 
development.  This  structure  should  be  reflected  in  numbering  the  capabilities. 

The  names  of  the  classes  should  be  meaningful  and  unique.  When  taken  with  the  information  provided 
by  the  class  template,  a  class  name  should  provide  a  clear  picture  of  the  capability  being  expressed  by 
the  class.  The  dass  description  provides  the  purpose  of  the  capability.  The  dependencies  into  the  dass 
are  desoribed  via  information  found  in  the  class  template. 

C.2.4  SRS  Paragraph  33.:  CSCI  Internal  Interfaces 

The  interfaces  between  capabilities  are  defined  in  terms  or  expressions  of  monitored  variables.  The 
system  context  diagram  shows  the  boundaries  between  the  software  and  the  monitored  and  controlled 
variables. 

C.2.5  SRS  Paragraph  3.4.:  CSCI  Data  Element  Requirements 

For  data  elements  internal  to  the  CSCI,  list  the  definitions  of  the  monitored  and  controlled  variables 
and  terms.  The  information  that  CoRE  requires  you  to  capture  about  each  of  these  provides  the 
information  required  by  this  section. 

For  data  elements  external  to  the  CSCI,  list  the  definitions  of  the  input  and  output  variables.  The 
information  that  CoRE  requires  you  to  capture  about  each  of  these  provides  the  information  required 
by  this  section. 

C.2.6  SRS  Paragraph  3.5.:  Adaptation  Requirements 

This  section  is  intended  to  specify  the  requirements  for  adapting  the  CSCI  to  site-unique  conditions 
and  to  changes  in  the  system  environment.  These  requirements  are  captured  in  the  NAT  relation,' 
which  captures  constraints  placed  on  the  environmental  variables  in  which  the  system  is  expected  to 
operate. 

C.2.7  SRS  Paragraph  3.5.1.:  Installation-Dependent  Data 

Site-unique  data  can  be  considered  a  constraint  on  the  environment.  If  you  choose  to  capture  this 
information  as  a  constraint,  the  appropriate  NAT  relations  would  be  listed  in  this  section. 

C2.8  SRS  Paragraph  3.5.2.:  Operational  Parameters 

Operational  needs  can  be  considered  constraints  on  the  environment.  If  you  choose  to  capture  this 
information  as  constraints,  the  appropriate  NAT  relations  would  be  listed  in  this  section. 
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CDU 

Command  and  Display  Unit 

C3l 

command,  control,  communications,  and  intelligence 

an 

centimeter 

Core 

Consortium  Requirements  ^igineering 

CRT 

cathode-ray  tube 

CSCI 

computer  software  configuration  item 

ERD 

entity-relationship  diagram 

FLMS 

Fuel  Level  Monitoring  System 

IN 

input 

ms 

millisecond 

NAT 

nature 

OUT 

output 

REQ 

required 

KTCP 

Radio  Tine  Control  Panel 

s 

second 

SRS 

Software  Requirements  Spedfication 

Abb-1 


LmtaiAbbtwiKliamaadAuoafm 


This  page  intentionally  left  blank. 


Abb-2 


GLOSSARY 


Abstraction 


Accuracy 


Attribute 


Behavioral  model 


Boundary  class 


Class 


Class  model 


Class  structure 


A  view  of  the  fM’c^lem  that  extracts  the  essential 
information  relevant  to  a  particular  purpose  and  ig¬ 
nores  the  remainder  of  the  information  (IEEE 
1983). 

A  quantitative  measure  of  the  magnitude  of  error 
(IEEE  1990).  Use  it  to  characterize  the  discrepancy 
between  the  actual  values  of  monitored  and  input 
variables  and  of  controlled  and  output  variables. 

Qtaracterizes  some  important  aspect  or  fact  about  an 
endy. 

The  behavioral  model  defines  the  required, 
externally  visible  behavior  in  terms  of  two  relations 
from  monitored  variables  to  controlled  variables. 
These  relations  are  NAT  and  REQ. 

Defines  monitored  and  controlled  variables  and 
potentially  encapsulates  the  corresponding  IN  and 
OUT  relations.  Boundary  dasses  serve  to  abstract 
from  detaUs  about  the  software's  interface  with  the 
environment. 

A  template  for  an  object  or  a  set  of  related  objects. 
A  class  defines  a  set  of  requirements  or  terms  com¬ 
mon  to  one  or  more  objects.  A  CoRE  requirements 
spedfication  is  written  in  terms  of  CoRE  classes. 

The  set  of  mechanisms  provided  by  CoRE  for 
defining  classes  and  their  relationships.  Provides  a 
set  of  facilities  for  packaging  the  behavioral  model  as 
a  set  of  classes  and  provides  the  mechanisms  to  man¬ 
age  requirements  dianges,  (xeate  reusable  require¬ 
ments,  and  develop  parts  of  the  software  in  parallel. 

The  set  of  classes  and  their  relationships  for  a 
particular  CoRE  specification.  The  class  structure 
for  a  CoRE  specification  is  constructed  using  the 
elements  of  the  dass  model. 


Gkvl 


Gtomy 


Complete 


Compound  condition 
Condition 

Condition  table 

Consistent 

Controlled  variable 

Controlled  variable  functions 

Demand 

Dependency 

Depends-on  relation 
Domain 


A  CoRE  specification  is  complete  when  the 
behavioral  model  defines  the  required  values  of  the 
controlled  variables  for  all  possible  values  of  the 
monitored  variables,  the  values  of  the  input  for  all 
possible  Values  of  the  monitored  variables,  and  the 
values  of  the  output  for  all  possible  values  of  the 
controlled  variables. 

Formed  by  connecting  two  or  more  conditions  using 
the  logical  operators  AND,  OR,  or  NOT 

Boolean  ex{»^ession  (predicate)  of  the  environmental 
variables  that  holds  for  a  continuous,  measurable  peri¬ 
od  of  time.  A  condition  characterizes  some  aspect  of 
the  environmental  state. 

A  tabular  representation  of  a  function  where  the 
domain  of  the  function  comprises  mode  and  a  set  of 
mutually  exclusive  conditions. 

A  CoRE  specification  is  internally  consistent  when 
the  CoRE  controlled  variable  functions  map  each 
value  in  the  domain  to  exactly  one  value  in  the  range 
and  when  no  two  parts  of  the  specification  are 
mutually  contradictory. 

Denotes  a  quantity  in  the  environment  that  the 
software  sets. 

Refers  to  the  set  of  functions  used  to  describe  the 
REQ  relation  for  a  controlled  variable.  This  includes 
the  value  function,  accuracy,  and  timing. 

Scheduling  requirement  that  is  associated  with  a 
controlled  variable  when  the  controlled  variable 
must  be  set  in  response  to  a  pericxlic  event. 

Exists  between  classes  X  and  Y  when  class  X  uses  T, 
where  T  can  be  a  monitored  variable,  term,  mcxle,  or 
event  pro'/ided  by  class  Y  only  if  X  employs  T  in  its 
definition. 

Denotes  which  classes  use  what  information 
provided  by  other  classes. 

A  relation  pairs  the  elements  of  one  set  with  the 
elements  of  a  second  set.  The  first  set  is  called  the 
domain  of  the  relation  (see  Range). 


Glo-2 


OkisMiy 


Dynamic  view 

Encapsulation 
Encapsulates  relation 
Encapsulation  structure 

Environmental  variables 

Entity 

Event 

Event  expression 
Event  occurrence 

Event  table 

Expression 

Finite  state  machine 

Four-variable  model 


Captures  the  required  timing  behavior  and  scheduling 
cimacteristics,  i.e.,  wdien  the  software  must  initiate  or 
complete  the  required  behavior. 

Process  of  hiding  details  and  other  decisions  by 
providing  an  abstract  interface. 

Class  X  encapsulates  class  Y  if  the  definition  of  Y  is 
part  of  the  encapsulated  information  of  X. 

The  encapsulates  relation  induces  a  hierarchy  on  the 
set  of  classes  called  the  encapsulation  structure. 

Core  views  a  system  as  existing  within  and  interacting 
with  an  environment.  The  quantities  in  the  environ¬ 
ment  that  are  relevant  to  the  software  are  denoted  by 
mathematical  variables  called  environmental 
variables. 

A  representation  of  ai^  aspect  of  the  system 
environment  of  interest  to  the  ^tem  that  can  describe 
physical  things,  roles  j^ayed  1^  persons  or  organiza¬ 
tions,  incidents,  and  interactions  that  are  significant  to 
the  software. 

Occurs  when  a  condition  changes  value. 

An  expression  used  to  represent  an  event  occunence. 

A  moment  in  time  when  a  condition’s  value  dianges. 
Each  event  occurrence  is  instantaneous  (takes  zero 
time)  and  atomic  (all  or  none  occurs). 

Ihbular  representation  of  a  function  where  the 
domain  of  the  function  comprises  modes  and  events. 

A  formula  that  defines  the  computation  of  a  value 
using  a  logical  symbol  or  a  meaningful  combination 
of  one  or  more  variables. 

A  computational  model  consisting  of  a  finite  number 
of  states  and  transitions  between  those  states, 
possibly  with  accompanying  actions  (IEEE  1990). 

The  Core  behavioral  model  is  based  on  a 
four-variable  model  in  which  the  four  variables  are 
monitored,  controlled,  input,  and  output. 


Glo-3 


Gkmaiy 


Function 

Functional  view 

Generalization/specialization  structure 

Hidden  information 
IN  relation 

Inheritance 

Input  variable 


Interface 

Mode 

Mode  machine 

Monitored  variable 

NAT  relation 


A  relation  between  two  sets  in  which  each  element  of 
the  one  set  (the  domain)  maps  to  no  more  than  one 
element  of  the  other  set  (the  range). 

A  view  of  the  software  behavioral  requirements  as  a 
set  of  functions,  i.e.,  what  values  the  system  must 
produce. 

Hierarchical  relationship  denoting  inheritance 
among  a  set  of  CoRE  dasses.  A  superclass  defines  a 
set  of  common  properties  inherited  by  its  subclasses. 

Details  or  dedsions  that  are  hidden  in  a  class. 

Describes  the  relationship  between  the  monitored 
variables  and  the  available  inputs. 

Denotes  the  requirements  or  terms  that  are  defined 
by  a  superclass  and  shared  among  its  subclasses. 

A  variable  representing  a  discrete  input  to  the 
software.  The  complete  definition  provides  a  predse 
description  of  how  the  software  reads  from  an  input 
device,  including  the  protocol  for  reading  from  a  de¬ 
vice  and  a  mapping  between  abstract  values  and  the 
bit  patterns  read  from  the  device. 

Information  defined  by  a  class  that  can  be  used  by 
other  classes  in  their  definitions. 

A  state  of  a  mode  machine. 

A  form  of  finite  state  machine.  Includes  a  collection 
of  system  modes  and  the  transitions  between  them. 
Differs  from  a  finite  state  machine  in  that  a  mode 
machine  does  not  define  actions. 

Denotes  an  environmental  quantity  that  the  software 
must  track. 

Describes  those  constraints  placed  on  the  system  by 
the  external  environment  (nature).  These 
constraints  are  properties  of  the  environment  that  af¬ 
fect  the  software  but  exist  whether  the  software  exists 
or  not. 


GkKsary 


Object 

OUT  relation 

Output  variable 


Periodic 


Precision 


Predicate 

Range 

Relation 

REQ  relation 

Selector  table 


An  object  is  a  subset  of  the  definition  of  REQ,  NAT 
IN,  and  OUT  (including  definitions  of  the  variables) 
for  a  given  specification  written  in  terms  of  the  four- 
variable  model.  Every  object  must  be  an  instance  of 
adass. 

Describes  the  relationship  between  the  controlled 
variables  and  the  available  software  outputs. 

A  variable  representing  a  discrete  output  of  the 
software.  The  complete  definition  provides  a  predse 
desoription  of  how  the  software  writes  to  an  output 
device,  including  the  protocol  for  writing  to  a  device 
and  a  mapping  between  abstract  values  and  the  bit 
patterns  sent  to  the  device. 

A  sdieduling  requirement  assodated  with  a 
controlled  variable  when  the  controlled  variable 
must  be  set  or  updated  at  regular,  fixed  time 
intervals. 

The  degree  of  exactness  or  discrimination  with  which 
a  quantity  is  stated  (IEEE  1990).  For  a  monitored 
variable,  the  predsion  expresses  how  accurately  the 
software  is  required  to  measure  the  actual  quantity 
that  the  monitored  variable  denotes.  For  a  controlled 
variable,  the  predsion  expresses  how  accurately  the 
software  must  be  able  to  set  the  actual  quantity  that 
the  controlled  variable  denotes. 

A  function  whose  range  is  the  elements  {true,  false}. 

A  relation  pairs  the  elements  of  one  set  with  the 
elements  of  a  second  set.  The  second  set  is  called  the 
range  of  the  relation  (see  Domain). 

Pairs  the  elements  of  one  set  (the  domain)  with  the 
elements  of  another  (the  range).  Each  element  of  the 
first  set  can  be  paired  with  one  or  more  elements  of 
the  second. 

Describes  properties  that  the  software  is  required  to 
maintain  between  the  monitored  and  controlled 
variables, 

Ihbular  representation  of  mode-dependent  informa¬ 
tion. 
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Glotiaiy 


State 


Subclass 


Superclass 


Tferm 


Testable 


Tblerance 


IVansition 


Undesired  event 
Value  function 


The  values  assumed  at  a  given  instant  by  the  set  of 
environmental  variables  (monitored  and  controlled). 

A  class  that  is  defined  as  an  instance  of  a  superclass. 
A  subclass  specializes  the  definition  of  its  superclass 
by  adding  or  constraining  requirements. 

A  class  that  defines  a  set  of  requirements  or  terms 
that  are  common  among  two  or  more  CoRE  classes. 

Named  expression  of  one  or  more  monitored 
variables  (or  other  terms) .  A  formula  that  defines  the 
computation  of  a  value  using  one  or  more  monitored 
variables  to  which  you  have  assigned  a  name. 

A  requirement  is  considered  testable  if  it  is  possible 
to  determine,  for  any  given  test  case  (i.e.,  an  input 
and  output),  whether  the  output  represents  an  ac¬ 
ceptable  behavior  of  the  software  given  the  input  and 
the  system  state.  In  other  words,  testable  require¬ 
ments  distinguish  precisely  the  set  of  acceptable  soft¬ 
ware  behaviors  in  terms  of  the  observable  behavior 
of  the  system. 

The  amount  of  variation  allowed  from  an  ideal  value 
of  a  controlled  variable. 

Occurs  between  modes  as  a  result  of  a  change  in  one 
or  more  environmental  variables. 

Failure  of  a  system  component  or  of  the  system  itself. 

Maps  each  value  of  the  monitored  variables  in  its 
domain  to  the  ideal  value  of  the  controlled  variable. 
The  value  function  specifies  the  ideal  behavioral 
requirements  of  a  controlled  variable. 
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definition  of,  2-1 
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interface,  9-4 
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defiiiition  ot  2-12 
template  for,  5-14 
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definition  of,  5-9 
example  of,  9-7,  B-7 
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illustration,  5-10 
Qass  model,  2-11 
5ee  efao  Packaging 
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contents  ot  5-4 
mterface,  5-1 

dependendes  on,  5-1 
semantics,  5-1 
^tax,5-l 
Class  structure 

See  abo  Padcaging 
capability  name,  C-2 
construction  of,  9-2 
definition  of,  2-11 
evaluation  o^  9-12 
inheritance,  2-14 
messages,  2-16 
notation,  5-6 
representation,  5-5 
revisiting,  10-11 
specification,  5-9 
subdass,  2-14 
superclass,  2-14 
use  of  dependent  graph,  9-3 
Condition 

compound,  4-4 
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example  of,  44 
predefined 

ENTERED,  4-9 
EXITED,  4-9 
INMODE,  4-9 
semantics  ol^  4-9 
sustaining,  Ifi-ll 
Condition  taUe 

See  also  Mode  madune 
completed  sample,  10-7 
create  value  function,  10-6 
defining  IN  relation,  11-4 
defining  OUT  relation,  11-5 
modes,  10-7 
template  for,  4-10 
Constant 

const_High_Alaim_Col 
definition  of,  B-17 
used,  B-21 

const_High_Alaim_Row 
definition  of,  B-17 
used,  B-21 

const_Hi^^RieI_Limit 
definition  B-10 
used,B-10 
oonst_H^tetesis 
definition  ot  B-10 
used,  B-10 
const_LCB 

definition  of,  B-10 
used,B-ll 

const_Level_Display_Row 
definition  o^  B-17 
used,  B-18 

const_Low_Alarm_Col 
definition  o^  B-17 
used,  B-22 

const_Low_Alaim_Row 
definition  of,  B-17 
used,  B-22 

constJLow__RielJLimit 
definition  of^  B-10 
used,  B-10 

const_Max_Level_Rate 
definition  of,  B-10 
used,  B-10 

coiist_Max_Tcstjnme 
definition  o^  B-7 
used,B-8 


const_MaxCol 

definition  of,  B-17 
used,  B'21 
const_MaxRow 

definition  o^  B-17 
used,  B-21 
const_MinCol 

definition  o^  B-17 
used,  B-21 
const_MinRow 

definition  ot  B-17 
used,  B-21 

const_Shutdown_Lock_'Iime 
definition  of,  B-7 
used,B-8 
const_UCB 

definition  ot  B-10 
used,B-ll 
Constraint 

demand,  10-5 
example  of,  10-8 
periodic,  10-8 

example  of,  10-8 
sdieduling,  10-8 
timing,  10-8 

consistency  check,  10-12 
tolerance,  10-9 

Context  diagram.  See  ^tem  context  diagram 
Controlled  state  function 
definition  of,  2-8 
range,  2-9 
Controlled  variable 

See  also  Environmental  variaUe 
con_AudiUe_Alarm 
definition  ol^  B-17 
OUT  relation,  B-22 
REQ  relation,  B-20 
con_Hi^_Alarm 
definition  of,  B-17 
OUT  relation,  B-21 
REQ  relation,  B-18 
oon_Level_Display 
definition  of,  B-17 
OUT  relation,  B-22 
REQ  relation,  B-19 
con_Low_Alarm 
definition  o^  B-17 
OUT  relation,  B-22 
REQ  relation,  B-19 
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con_Shutdown_Relay 
'definition  of,  B-13 
OUT  relation,  B-14 
REQ  relation,  B-13 
data  element  requirement,  C-2 
defined  with  OUT  relation,  4-2 
defining  function,  4-1 
definition  of,  2-S 
delay  requirement,  4-3 
determining  range  of  values,  11-5 
example  of,  B-13 
identification  of,  8-2 
internal  interface,  C-2 
output  resources,  11-1 
periodic  or  demand,  8-10 
precision  specification,  8-6 
scheduling  requirement,  4-3 
value  of,  4-2 

Controlled  variable  function 
analysis 

completeness,  12-1 
consistency,  12-2 
definition  of,  8-7 
domain,  8-4 

Core 

definition  1-1 

DoD-STD-2167A  specification  (SRS),  C-1 
dynamic  view,  4-3 

representation,  4-12 
functional  view,  4-1 
illustration,  4-2 
representation,  4-3 
process,  6-1 
purpose  of,  2-2 
representation  of,  4-1 
tables,  4-9 

condition,  4-10 
event,  4-10 
selector,  4-12 


Demand  behavior,  specification  of,  10-S 
Dependency  graph 

See  tdso  Qass  structure 
example  of,  B-6 
notation,  5-7 
reasons  for,  9-3 
relationships,  S-7 
Depends-on  relation 
definition  of,  2-13 
illustration  of,  2-13 


Encapsulated  information 
decomposition,  S-10 
example  of,  B-7 
identification  of,  9-3 
illustration,  5-10 
IN  and  OUT  rdations,  11-2 
input  and  output  variaUes,  11-2 
notation,  5-10 
Entity 

definition  of,  5-2 
example  of,  5-2 
on  ERD,  5-2 
tenq>late  of,  5-2 
Environmental  variaUe,  2-5 
analysis 

completeness,  12-1 
consistency,  12-1 
controlled  variaUe,  2-5 
definition  of,  8-5 
evaluation  criteria 
conq>leteness,  10-11 
consistency,  10-12 
identifying,  8-2 
initial  value,  10-3 
sustaining  condition,  10-3 
from  information  mcxiel,  5-2 
monitored  variable,  2-5 
definition  of,  8-5 
state  diaracterization,  4-1 
template 

physical  interpretation,  4-3 

fype,4-3 

values,  4-3 

Event 

based  on,  4-2 
definition  of,  4-1 
event_Reset 

definition  of,  B-23 
used,B-8 
event_SeIftest 

definition  ot,  B-23 
used,B-8 
event_Set_Digit 

definition  of,  B-18 
used,  B-22 
example  of,  9-9,  B-16 
expression,  4-4 

@F  expression,  4-4 
@T  etqpression,  4-4 
example  of,  4-4 
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Older  of  evaluation,  4-S 
occurrence,  4-4 
periodic  timing,  10^ 

Event  table,  template  for,  4-11 
Existing  skills 

requirement  for,  1-1 
where  met,  2-lS 


FLMS,B-5 

iQustration,  3-1 
narrative,  3-1 
Formal  model 

requirement  for,  1-1 
where  met,  2-7 
Four-variable  model 
definition  ot  2-S 
relations  of,  4-2 
use  in  CoRE,  4-1 


Global  checking 

completeness,  12-3 
consistency,  12-3 
Graphical  specifications 
requirement  for,  1-1 
where  met,  2-15 
Guidance,  requirement  for,  1-2 
Guidebook 

description,  1-2 
orgianization,  1-3 
scope,  1-3 
use  o^  1-4 


Hardware  resources 
definition  of,  11-1 
example  o^  11-1 

Hid^n  information.  See  Encapsulated  information 


Idealized  CoRE  process 
definition  of,  6-1 
stages  of,  6-3 

class  structuring,  9-1 
define  hardware  interface,  11-1 
detafled  behavior  specification,  10-1 
identify  environmental  variables,  7-1 
preliminary  behavior  specification,  8-1 


IN  relation 
aiuifysis 

completeness,  12-3 
consistency,  12-3 
definition  of,  2-6, 2-9, 11-3 
drmiain  of,  2-10 
example  of,  B-IS 

exter^  interface  requirements,  C-2 
hardware  interfiice,  6-6 
rang^  of,  2-10 
Information  model 
See  also  Class  model 
attributes,  7-3 
example  of,  7-4 
sources  of,  7-3 
composition  o^  7-3 
construction  of 

behavioral  model,  S-2 
dass  model,  5-2 
definition  of,  7-2 
entities,  7-5 

exanqrle  of,  7-6 
sources  ot  7-5 
example  of,  7-6 
identifying 
classes,  S-2 

environmental  variaUes,  5-2 
relations,  7-5 

exarrqrle  o^  7-9 
sources  of,  7-6 
representation  of 

attribute  matrix,  7-9 
ERD,7-6 
Inheritance 

description  of,  5-12 
generalization/specialization,  5-12 
notation,  5-13 
Initial  mode 

identification  of,  4-7 
transition  from,  4-7 
Input  variaUe 

allocation  of,  11-2 
completing  definition,  11-3 
data  element  requirement,  C-2 
definition  of,  2-6 
evaluation  criteria,  11-6 
^mple  of,  B-10 
IN  relation,  11-1 
in_QkPulse 

definition  of,  B-IS 
IN  relation,  B-IS 


IimM 


in_Diff_Press 

definition  of,  B-10 
IN  relation,  B-11 
in_Reset_Device 
definition  of,  B-23 
IN  relation,  B-24 
in_Selftest_Device 
definition  of,  B-24 
IN  relation,  B-24 

mapping  to  monitored  variable,  11-S 
spedfication  ot,  11-2 
template  for,  11-3 
Interface 

definition  of,  2-12 
specification  of,  11-2 
Internal  dass,  purpose  of,  6-4 


Mode 

anafysis 

completeness,  12-2 
oonsisten<7, 12-2 
based  on,  4-2 
example  of,  9-7,  B-7 
identification  of,  8-9 
mode_BadLevDev 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_dass_In_Operation 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_Hazard 

definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_Operating 
defi^tion  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
mode_Shutdown 
definition  of,  B-8 
used,  B-13,  B-18,  B-19,  B-20 
modeJIbst 

definition  of,  B-8 
used,  B-7,  B-13,  B-18,  B-19,  B-20 
system,  8-11 

Mode  das.  See  Internal  dass;  Mode  machine 
Mode  machine 

See  also  Internal  dass 
capability  requirements,  C-2 
construction  of,  9-2, 10-6 
sample,  10-7 
contents  of,  4-6 


defining  set  of  modes,  8-12 
definition  of,  8-10 
example  of,  8-12 
identification  of,  8-10 
illustration,  4-2 
initial  value,  10-11 
properties,  4-9 
purpose  of,  4-1 
refinement  o^  10-9 
representation  of 

See  also  Mode  transition  diagram 
example,  4-7 

mode  transition  taUe,  4-7 
state  transition  diagram,  8-12 
specification  of,  6-4 
state  madiine,  4-6 
Mode  transition  diagram 
definition  of,  4-7 
transition  events,  4-7 
Mode  transition  table 
definition  of,  4-7 
example  of,  4-8 
Monitored  state  function 
definition  of,  2-8 
domain  of  REQ,  2-9 
Monitored  variaUe 

See  also  Environmental  variable 
data  element  requirement,  C-2 
defined  with  IN  relation,  4-2 
definition  of,  2-S 
determining  range  of  values,  11-4 
example  of,  9-5,  B-9 
for  undesired  event,  4-17 
ideal  value  function,  4-1 
identification  of,  8-3, 8-8 
input  resources,  11-1 
internal  interface,  C-2 
mon_Ftiel_Level 
definition  of,  B-9 
IN  relation,  B-11 
NAT  relation,  B-10 
used,  B-10,  B-19 
mon_Fuel_Level_Unknown 
definition  of,  B-9 
IN  relation,  B-11 
used,  B-8 
mon_ResetjSwitdi 
definition  of,  B-23 
IN  relation,  B-24 
used,  B-23 
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mon_Selftest_Switch 
definition  of,  B-23 
IN  relation,  B-24 
used,  B-23 
monJTime 

definition  of^  B-IS 
IN  relation,  B-IS 
NAT  relation,  B-10 
used,B.17 
timing  constraint,  4-1 
tolerance  function,  4-1 
use  in  terms,  4-1 


NAT  relation 

adaptation  requirement,  C-2 
definition  of,  2-6, 2-8 
domain  of,  2-8 
operational  parameter,  C-4 
range  of,  2-8 
specification  of,  4-16 
Nonalgorithmic  specification 
requirement  for,  1-1, 2-3 
where  met,  2-7 
Notation 

conventions,  1-4 
requirement  for,  1-1 


Object 

as  class  instance,  5-10 
definition  of,  2-12 
specification  of,  5-11 
Object-oriented  model 
requirement  for,  1-1 
where  met,  2-1, 2-11 
OUT  relation 
analysis 

completeness,  12-3 
consistency,  12-3 
definition  of,  2-6, 2-9, 11-3 
domain  of,  2-10 
example  of,  B-14 

exter^  interface  requirements,  C-2 
hardware  interface,  6-6 
range  of,  2-10 
Output  variaUe 

allocation  of,  11-2 
completing  definition,  11-3  ' 
data  element  requirement,  C-2 


definition  of,  2-6, 11-2 
evaluation  criteria,  11-6 
example  of,  B-14 

mapping  to  controlled  variaUe,  11-5 
OUT  relation,  11-1 
out_Character 

definition  of,  B-21 
OUT  relation,  B-21,  B-22 
used,  B-18 
out_Cursor_Col 
definition  of,  B-21 
OUT  relation,  B-21,  B-22 
used,  B-18 
out_Cursor_Row 
definition  of,  B-21 
OUT  relation,  B-21,  B-22 
used,  B-18 
out_Shutdown 

definition  of,  B-14 
OUT  relation,  B-14 
specification  of,  11-2 
template  for,  11-3 


Packaging 

See  also  Class  structure;  Encapsulated 
information 

allocation  of  information,  9-1 
illustration  (canonical),  2-15 
creating  dasses  for,  9-2 
definition  of,  2-1 
goals  of,  9-1 
reasons  for,  2-4 
relationships,  2-12 
dependency,  2-13 
encapsulation,  2-12 
generalization/specialization,  2-14 
Periodic  behavior,  spec^cation  of,  10-6 
Physical  interpretation 

enumerated  variables,  8-7 
use  of,  8-7 
Precision 

specification  o^  8-6 
use  of,  8-6 
Procedure 

example  of,  FLMS,  8-11 
specification  of,  8-11 


Recursion.  See  Recursion 
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Relationship 

aggregation,  5-3 
illustration,  S-4 
application-specific,  S-4 
description  of,  5-2 
general^tion/spedalization,  S-3 
fllustration,  S-3 
REQ  relation 

consistency,  10-12 
definition  of,  2-6, 2-9 
derived  information,  8-12 
domain  of,  2-9 
example  o^  B-13 
range  of,  2-9 

sizing  and  timing  requirement,  C-2 
specification  ol^  4-lS 
Rigorous  specifications 
requirement  for,  1-1 
where  met,  2-1, 2-4 


Scheduling 

demand,  4-14 

illustration,  4-14 
identify  requirements,  8-9 
periodic,  4-13 

constraint,  10-6 
illustration,  4-14 
Selector  taUe 

create  value  function,  10-6 
definition  of,  4-12 
example  of,  4-12 
template  for,  4-12 
Separation  of  concerns 
requirement  for,  2-3 
where  met,  2-5 
State 

representation  of 
decision  table,  4-6 
state  transition  diagram,  4-6 
value  ot  4-6 
System  constraint 

evaluation  criteria,  7-10 
exit  oiteria,  7-10 
identification  of 

environmental  variable,  7-3 
likely  requirements  changes,  7-9 
System  context  diagram 
development  of,  8-7 
example  of,  B-S 


leveling,  S-8 

illustration,  S-8 
notation,  S-6 

representation  of  overview,  5-7 
use  of,  S-6 
System  function 
example  of,  8-11 
representation  of,  8-11 


Tbrm 

analysis 

completeness,  12-2 
consistency,  12-2 
construction  of,  9-4 
example  of,  9-5,  B-10 
reasons  for,  4-6 
term_Digit 

definition  of,  B-17 
used,  B'18 
term_Flash_On 

^finition  of,  B-17 
used,  B'18,  B-20 
term_Fuel_Level_Rangp 
definition  of,  B-10 
used,  B-8,  B-18,  B-20 

term_Inside_Hys_Range,  definition  of,  B-10 
term_Level_Display_Digit 
^finition  of,  B-18 
used,  B'18 
termJTestJfime 
definition  of,  B-7 
used,  B-19,  B-20 
type,  4-6 
use  of,  4-1 
value,  4-6 

Uming  and  scheduling  requirements 
constraints,  10-12 
template  for,  10-11 
Tolerance,  function,  10-12 


Undesired  event 

description  of,  4-17 
iiubility  to  determine  value,  8-4 
specification  of,  4-17 

Value  function 

See  also  Controlled  variable 
analysis  of,  10-6 
completeness,  10-11 
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condition  table,  10-12 
creation  of,  10-4 
event  table,  10-12 
initial  value,  10-11 
periodic  timing  constraint,  10-6 
response  to  event,  10-6 
specification  of,  10-1 
Value-dependent  variation 
definition  of,  10-9 
example  of,  10-9 
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